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References:  See  Enclosure  F 
1.  Purpose 

a.  Establish  policies  and  procedures  for  the  requirements  generation 
system  called  for  by  reference  a. 

b.  Provide  policies  and  procedures  for  developing,  reviewing, 
validating,  and  approving  Mission  Need  Statements  (MNSs),  and 
Operational  Requirements  Documents  (ORDs)  required  by  reference  b. 

c.  Provide  policies  and  procedures  for  developing,  reviewing, 
validating,  and  approving  Capstone  Requirements  Documents  (CRDs). 

d.  Delegate  oversight  authority  for  the  requirements  generation 
system  to  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff,  assisted  by  the 
Joint  Requirements  Oversight  Council  (JROC)  and  members  of  the  Joint 
Staff. 

e.  Provide  guidelines  for  the  conduct  of  requirements  and  program 
reviews  at  each  milestone  for  Major  Defense  Acquisition  Programs 
(MDAPs)  prior  to  their  being  forwarded  for  Defense  Acquisition  Board 
(DAB)  review  and  Major  Automated  Information  System  (MAIS) 
acquisition  programs  prior  to  their  being  forwarded  to  ASD(C3I)  or 
appropriate  component  acquisition  executive  and  JROC  Special  Interest 
programs. 
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f.  Define  the  role  of  the  JROC  Secretary  as  the  Joint  Staff  point  of 
contact  for  the  submission,  handling,  and  review  of  MNSs,  CRDs,  and 
ORDs. 

2.  Cancellation.  CJCSI  3170.01,  dated  13  June  1997,  is  canceled. 

3.  Applicability.  This  instruction  applies  to  the  requirements  generation 
system  of  the  Joint  Staff,  Services,  unified  commands,  and  those  DOD 
field  activities  and  Defense  agencies  supporting  the  defense  acquisition 
responsibilities  of  the  Chairman  of  the  Joint  Chiefs  of  Staff.  This 
instruction  also  applies,  in  general,  to  other  agencies  preparing  and 
submitting  requirements  in  accordance  with  references  a  and  b.  Highly 
sensitive  classified  programs  will  comply  with  this  instruction,  but  will  be 
tailored  as  necessary  to  account  for  special  security  considerations 
(reference  a,  page  2,  and  reference  b,  part  I,  paragraph  1.4).  This 
instruction  does  not  preclude  the  need  to  refer  to  the  basic  DOD  5000 
series  documents  for  guidance  and  direction  on  defense  acquisition.  All 
DOD  components  responsible  for  generating  requirements  documents 
will  base  their  respective  procedures  for  ACAT  II  and  below  programs  on 
those  contained  in  this  instruction.  Application  of  these  common 
formats  to  all  requirements  documentation  will  provide  better  visibility, 
recognition,  and  accommodation  of  joint  requirements  opportunities  and 
interoperability  issues  earlier  in  the  requirements  generation  process. 

4.  Policy 


a.  Authority.  The  Chairman  of  the  Joint  Chiefs  of  Staff  assesses 
military  requirements  for  defense  acquisition  programs  and  represents 
the  CINCs  with  respect  to  their  operational  requirements  (reference  c, 
sections  153  and  163,  respectively).  The  JROC  facilitates  the  execution 
of  these  responsibilities  (reference  c,  section  181,  and  reference  g  for 
mission  and  organization,  roles,  and  responsibilities). 

b.  Service  Role.  The  Services  are  responsible  for  organizing, 
supplying,  equipping  (including  research  and  development) ,  training, 
administering,  and  related  functions  in  order  to  meet  the  current  and 
future  operational  requirements  of  the  unified  commands.  They  are  also 
charged  with  eliminating  duplication  through  effective  cooperation  and 
coordination  with  the  other  Services  and  DOD  agencies  (reference  c, 
sections  3013,  5013,  and  8013). 

c.  CJCS  Role.  The  Chairman  of  the  Joint  Chiefs  of  Staff,  assisted  by 
the  Vice  Chairman  and  other  members  of  the  Joint  Chiefs  of  Staff, 
establishes  and  publishes  policies  and  procedures  governing  the 
requirements  generation  system. 
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d.  VCJCS  Role.  The  Vice  Chairman,  assisted  by  the  JROC,  will 
oversee  the  requirements  generation  system  in  accordance  with  DOD 
5000  series  documents  and  policies  and  procedures  contained  in  this 
instruction  to  ensure  the  responsibilities  of  the  Chairman  under  title  10, 
United  States  Code,  are  fulfilled. 

e.  DOD  Chief  Information  Officer  (CIO)  Role.  The  DOD  CIO  is 
responsible  to  ensure  the  interoperability  of  information  technology  and 
national  security  systems  throughout  the  DOD.  DOD  CIO  will  ensure 
that  information  technology  and  national  security  systems  standards 
that  will  apply  throughout  the  DOD  are  prescribed  and  provide  for 
elimination  of  duplicate  information  technology  within  and  between  the 
military  departments  and  Defense  agencies  (reference  s). 

f.  Implementation  and  Supplementation.  This  instruction  will  not  be 
supplemented  without  the  prior  approval  of  the  Vice  Chairman  of  the 
Joint  Chiefs  of  Staff  or  his  delegated  representative. 

5.  Definitions.  Definitions  are  provided  in  the  Glossary. 

6.  Responsibilities .  See  Enclosure  B. 

7.  Summary  of  Changes.  This  revision  reflects  major  reformat  of  the 
document;  major  changes  include  document  submission  for  Automated 
Information  Systems,  substantive  update  to  the  CRD  enclosure  and 
format,  substantive  update  to  the  ORD  enclosure  and  format,  mandates 
Interoperability  Key  Performance  Parameters  for  CRDs  and  ORDs  and 
defines  time-phased  requirements  in  support  of  evolutionary  acquisition, 
addresses  program  affordability  for  ORDs,  defines  US  Atlantic  Command 
role  for  interoperability,  and  clarification  of  definitions. 

8.  Releasability.  This  instruction  is  approved  for  public  release; 
distribution  is  unlimited.  DOD  components  (to  include  the  combatant 
commands),  other  Federal  agencies,  and  the  public  may  obtain  copies  of 
this  instruction  through  the  Internet  from  the  CJCS  Directives  Home 
Page— http:/ /www. dtic.mil/doctrine.  Copies  are  also  available  through 
the  Government  Printing  Office  on  the  Joint  Electronic  Library  CD-ROM. 


//Signed  17  Aug  1999// 

C.W.  FULFORD,  JR. 

Lieutenant  General,  U.S.  Marine  Corps 
Director,  Joint  Staff 
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Enclosures: 

A  —Requirements  Generation  System 
B  —Requirements  Generation  Process 
C  —Mission  Need  Statement  (MNS)  Generation  Process 
Appendix  A— Mission  Need  Statement  Format 
Appendix  B— Notional  Joint  Mission  Need  Analysis  Working 
Groups 

D  —Capstone  Requirements  Document  Generation  Process 
Appendix  A— Capstone  Requirements  Document  Format 
E  —Operational  Requirements  Document  Generation  Process 
Appendix  A— Operational  Requirements  Document  Format 
F  —References 
GL— Glossary 
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ENCLOSURE  A 

REQUIREMENTS  GENERATION  SYSTEM 


1.  Requirements  Generation  System.  The  requirements  generation 
system,  along  with  the  acquisition  management  system  and  the 
Planning,  Programming,  and  Budgeting  System,  form  DOD’s  three 
principal  decision  support  systems  (see  Figure  1).  A  close  and  effective 
interface  among  these  systems  is  required  to  ensure  quality  products  are 
acquired  for  the  Nation’s  Armed  Forces.  The  requirements  generation 


Figure  1 .  The  Three  DOD  Decision  Support  Systems 

system  produces  information  for  decision  makers  on  the  projected 
mission  needs  of  the  warfighter.  These  mission  needs  are  defined  in 
broad  operational  terms  in  a  Mission  Need  Statement  (MNS)  document. 
MNSs  are  prepared  for  needs  that  develop  into  warfighter’s  operational 
requirements  that  could  result  in  new  Defense  acquisition  programs. 
Validation  of  the  MNS  confirms  the  fact  that  a  non-materiel  solution 
alone  cannot  satisfy  the  identified  need,  and  that  a  potential  “new 
concept/ system”  materiel  solution  should  be  considered.  Subsequently, 
the  needs  expressed  in  the  MNS  are  developed  into  requirements  by  the 
Requirements  Generation  Process  in  the  forms  of  Capstone  Requirements 
Documents  (CRDs)  (if  required)  and  Operational  Requirements 
Documents  (ORDs).  CRDs  provide  ORD  development  guidance  through 
validated  performance  based  overarching  capabilities  for  a  mission  area 
that  forms  a  system  of  systems  or  family  of  systems.  ORDs  translate  the 
MNS  and  (if  applicable)  CRD  requirements  into  detailed,  refined 
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performance  capabilities  and  characteristics  of  the  proposed  system. 

ORDs  provide  the  specific  requirements  base  for  the  Acquisition 
Management  System  and  the  PPBS  for  advanced  Defense  acquisition 
program  development,  programming  and  budgeting.  (Figure  2)  highlights 
the  interface  of  the  requirements  and  acquisition  systems. 

Program  Definition  &  Engineering  &  Production, 

Risk  Reduction  Manufacturing  Fielding/Deployment 

i  Development  ,  &  Operational  Support 

'  !  ! 

MS  I  MS  II  MS  III 


JROC  DAB/  JR0C  JR0C  DAB/  JR0C  DAB/  JROC  dab/ 

Acq  Exec  Acq  Exec  Acq  Exec  Acq  Exec 

Figure  2.  Requirements  and  Acquisition  Interface. 


2.  Two  areas  that  will  have  significant  impact  on  the  future  of  the 
requirements  generation  system  are  joint  requirements  and  DOD 
initiatives  toward  evolutionary  acquisition  which  intends  to  provide 
quality  products  to  the  warfighter  in  a  timely  manner. 


Determination  Concept  Exploration 
of  Mission 
Need 


MS  0 


a.  Joint  Requirements.  Joint  requirements  are  requirements  that 
impact  more  than  one  DOD  component.  All  C4I  and  ISR  systems  for 
purposes  of  compatibility  and  interoperability  and  integration  are 
considered  joint.  Programs  having  a  Joint  Potential  Designator  (JPD)  of 
Joint  or  programs  designated  as  "joint"  will  become  more  numerous  over 
time  and  need  to  be  developed  with  participation  of  all  DOD  components. 
Joint  requirement  responsibilities  and  procedures  are  addressed  in  the 
enclosures  of  this  instruction. 


b.  Time-Phased  Requirements  in  support  of  Evolutionary  Acquisition. 

As  DOD  moves  to  reduce  cycle  time  of  traditional  acquisition  activities, 
through  evolutionary  acquisition,  there  needs  to  be  an  effective 
mechanism  for  specifying  operational  requirements  to  support  this 
process.  Time-phased  requirements  is  an  approach  to  consider 
requirements  in  an  incremental  manner  over  time  such  that  they  match 
projected  threat  and  technology  to  deliver  systems  to  the  field  in 
increasing  increments  of  capability.  Specific  guidance  is  provided  in 
Enclosure  E. 
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ENCLOSURE  B 

REQUIREMENTS  GENERATION  PROCESS 

1.  Requirements  Generation  Process.  The  requirements  generation 
process  will  be  uniform  throughout  the  Department  of  Defense. 
Specifically,  the  generation  of  requirements  will  consist  of  the  following 
four  distinct  phases:  definition,  documentation,  validation,  and  approval. 
As  a  system  evolves  from  a  MNS,  to  a  CRD  (if  applicable),  through  ORDs, 
there  are  differences  in  what  is  accomplished  in  each  phase.  A  general 
description  of  each  phase  is  provided  below  while  specific  MNS,  CRD, 
and  ORD  procedures  for  each  phase  are  described  in  the  appropriate 
enclosures  of  this  instruction. 

a.  Definition  Phase.  The  definition  phase  defines,  analyzes, 
evaluates,  and  justifies  the  development  of  a  requirements  document. 

For  MNSs  the  evaluation  is  best  accomplished  by  a  Mission  Area  Analysis 
(MAA)  and  Mission  Need  Analysis  (MNA)  or  equivalent  DOD  component 
process.  CRDs  can  use  concept  development  studies,  analysis  expanded 
from  the  MAA/MNA  for  the  mission  area,  inputs  from  exercises, 
operational  experience  and  experimentation.  ORDs  can  use  Analysis  of 
Alternatives  (AO A),  demonstrations  of  military  utility,  and 
experimentation  inputs. 

b.  Documentation  Phase.  The  formal  preparation  and  initial  DOD 
component  review  of  required  and  standardized  documents  in  support  of 
a  defined  mission  need  is  the  documentation  phase.  The  MNS  is  a  non- 
system-specific  statement  of  operational  capability  need  written  in  broad 
operational  terms.  The  CRD  captures  the  overarching  requirements  for  a 
mission  area  that  forms  a  family- of- systems  (FoS)  (e.g.,  space  control, 
theater  missile  defense)  or  System-of-Systems  (SoS)  (e.g.,  national  missile 
defense).  The  ORD  translates  the  MNS  into  more  detailed  and  refined 
performance  capabilities  and  characteristics  of  a  proposed  concept  or 
system.  Requirements  evolution  is  depicted  in  Figure  3. 


B-l 


Enclosure  B 


CJCSI  3170.01A 
10  August  1999 


Figure  3.  Requirements  Documentation  Evolution 

c.  Validation  Phase.  The  validation  phase  is  the  formal  review 
process  of  a  requirements  document,  by  an  operational  authority  other 
than  the  user,  to  confirm  the  identified  need  and  operational 
requirement.  The  validation  authority  for  MNSs,  CRDs,  and  ORDs  is 
dependent  upon  potential  ACAT  level  and/or  if  a  program  is  designated 
JROC  special  interest. 

d.  Approval  Phase.  The  approval  phase  documents  the  approval 
authority’s  concurrence  with  the  final  validated  document.  Approval  is  a 
formal  sanction  that  the  validation  process  is  complete  and  the  identified 
need  or  operational  capabilities  described  in  the  documentation  are  valid. 
Approval  authority  is  dependent  upon  potential  ACAT  level,  if  designated 
JROC  special  interest,  or  if  approval  authority  has  been  delegated. 

2.  Responsibilities 

a.  JROC.  Title  10,  section  181,  the  DOD  5000  series,  and  reference 
g,  specifically  delineate  the  JROC's  responsibilities.  The  JROC  will  assist 
the  Chairman  in  identifying  and  assessing  the  priority  of  joint  military 
requirements  and  acquisition  programs  to  meet  the  National  Military 
Strategy.  The  JROC  reviews  potential  ACAT  I/LA  and  JROC  special 
interest  programs  to  support  the  DAB/DOD  CIO  review  process 
respectively.  The  JROC  also  assists  the  Chairman  in  considering 
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alternatives  to  any  acquisition  program  that  has  been  identified  to  meet 
military  requirements  by  evaluating  performance,  cost,  and  schedule. 

The  JROC,  at  its  discretion,  may  review  any  requirements  document  and 
AC  AT  II  and  below  acquisition  programs  to  resolve  contentious  or  joint 
interest  issues.  The  JROC  will  also  review  programs  at  the  request  of  the 
Secretary  of  Defense,  Deputy  Secretary  of  Defense,  Under  Secretary  of 
Defense  for  Acquisition  and  Technology  (USD(A&T)),  or  Assistant 
Secretary  of  Defense  for  Command,  Control,  Communications,  and 
Intelligence  (ASD(C3I)).  The  JROC  Secretariat  will  notify  the  appropriate 
DOD  component  via  JROC  Staffing  Memorandum  (JROCSM)  identifying 
the  document  or  program  as  JROC  special  interest. 

b.  Joint  Staff  and  Defense  Intelligence  Agency  (DIA).  The  Joint  Staff 
and  DIA  provide  an  important  review,  coordination,  and  certification 
function  in  support  of  the  MNS,  CRD,  and  ORD  validation  and  approval 
process.  These  functions  include  interoperability  certification; 
intelligence  certification;  threat  validation;  aviation  munitions 
interoperability  and  munitions  insensitivity  certification  and  the  staffing 
of  all  documents  that  the  JROC  reviews. 

(1)  Director.  J-2,  Joint  Staff,  and  Director.  DIA 

(a)  Threat  Validation.  DIA  will  provide  threat  validation 
appropriate  to  the  projected  lifespan  of  the  system  on  intelligence 
information  used  in  potential  AC  AT  I  and  JROC  special  interest  MNSs, 
CRDs,  and  ORDs.  DOD  components  may  validate  intelligence 
information  for  their  own  ACAT  II  and  below  programs  using  DIA 
validated  threat  data  and/or  data  contained  in  DOD  Intelligence 
Production  Program  (DoDIPP)  documents. 

(b)  Intelligence  Certification.  DIA  will  certify  all  MNSs,  CRDs, 
ORDs,  regardless  of  ACAT  level,  for  intelligence  supportability  and  impact 
on  joint  intelligence  strategy,  policy,  and  architecture  planning.  The  DIA 
certification  will  also  evaluate  open  systems  architecture, 
interoperability,  and  compatibility  standards  for  intelligence  handling 
and  intelligence-related  information  systems.  DIA  will  forward 
intelligence  certification  to  the  JROC  for  ACAT  I  and  JROC  special 
interest  programs  or  to  the  sponsoring  DOD  component  or  agency  for 
ACAT  II  and  below.  Unresolved  intelligence  issues  will  be  forwarded  by 
DIA  to  the  Military  Intelligence  Board  (MIB)  for  resolution.  Director  of 
DIA  will  ensure  that  unresolved  issues  resulting  from  intelligence 
assessments  are  presented  to  the  JROC  for  resolution  at  each  milestone 
review. 
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(c)  C4I  Support  Plans  (C4ISP).  J-2  and  DIA  will  review  and 
assess  ISR  requirements  and  supportability  in  the  C4ISP  as  described  in 
reference  b.  DIA/J2  will  forward  certification  of  intelligence 
requirements  supportability  to  ASD(C3I).  A  sample  C4ISP  is  contained  in 
reference  p. 

(2)  Director,  J-3,  Joint  Staff.  J-3  is  the  Office  of  Prime 
Responsibility  for  the  Global  Command  and  Control  System  (GCCS)  and 
Common  Operational  Picture  (COP).  IAW  CJCSI  6721.01  (reference  j).  J- 
3  will  review  all  GCCS  functional  requirements  identified  in  ORDs. 

(3)  Director.  J-4.  Joint  Staff 

(a)  Aviation  munitions.  J-4  will  certify  all  potential  ACAT  I 
MNSs  and  ORDs  for  aviation  munitions  for  cross-Service  interoperability. 

(b)  Insensitive  munitions.  J-4  will  certify  that  all  ORDs  for 
munitions,  regardless  of  ACAT  level,  contain  the  requirement  to  conform 
with  insensitive  munitions  (unplanned  stimuli)  criteria.  As  a  minimum, 
these  ORDs  will  contain  the  statement  "Munitions  used  in  this  system 
will  be  designed  to  resist  insensitive  munitions  threats  (unplanned 
stimuli)." 


(c)  Insensitive  Munitions  Waiver  Requests.  Insensitive 
munitions  and  cross-Service  interoperability  waiver  requests  require 
approval  by  the  JROC.  Waiver  requests  will  be  submitted  to  J-4  for 
review  and  then  forwarded  to  the  JROC  secretariat  for  JROC 
consideration. 

(4)  Director.  J-6,  Joint  Staff 

(a)  Interoperability  Certification.  J-6  will  certify  MNSs,  CRDs, 
and  ORDs,  regardless  of  ACAT  level,  for  conformance  with  joint  C4  policy 
and  doctrine,  technical  architectural  integrity,  and  interoperability 
standards.  J-6  will  review  and  comment  on  Interoperability  KPPs  and 
coordinate  C4  issues  concerning  MNSs,  CRDs,  and  ORDs  with  the 
appropriate  agencies  IAW  reference  h  as  directed  by  references  1  and  m. 
The  J-6  will  forward  C4  interoperability  certification  to  the  JROC  for 
ACAT  I/LA  and  JROC  special  interest  programs  or  to  the  sponsoring  DOD 
component  for  ACAT  II  and  below  programs.  Unresolved  interoperability 
issues  will  be  forwarded  by  J-6  to  the  Military  Communications- 
Electronics  Board  (MCEB)  for  resolution.  The  MCEB  will  ensure  that 
unresolved  issues  resulting  from  interoperability  assessments  are 
presented  to  the  JROC  for  resolution. 
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(b)  C4I  Support  Plans.  J-6  will  review  and  assess  the  C4 
requirements  in  the  C4ISP  (IAW  reference  h),  as  described  in  reference  b. 

(5)  Director.  J-7,  Joint  Staff.  As  the  Executive  Agent  for  Joint 
Vision  Implementation,  J-7  will  utilize  the  Joint  Vision  Implementation 
Master  Plan  (reference  d)  to  review  recommendations  resulting  from  Joint 
Experimentation  that  will  affect  joint  doctrine,  organizations,  training 
and  education,  materiel,  leadership,  and  personnel  (DOTMLP). 
Recommendations  indicating  potential  materiel  solutions  will  be 
forwarded  to  the  JROC  for  review. 

(6)  Director.  J-6.  Joint  Staff.  Director,  J-8,  is  the  appointed  JROC 
Secretary  whose  staff  makes  up  the  JROC  Secretariat.  Specific 

J-8  responsibilities  are  outlined  in  reference  g. 

c.  Services.  Services  will  define  mission  needs  and  operational 
requirements  and  will  develop  and  coordinate  the  documentation  with 
the  appropriate  DOD  components.  The  Service  functions  as  validation 
and  approval  authority  for  Service-generated  MNSs  and  ORDs  ACAT  II 
and  below  unless  designated  JROC  special  interest.  An  MNS  validated 
by  a  CINC  and  forwarded  for  action  to  a  Service  does  not  need  to  be 
revalidated  by  the  Service. 

d.  CINCs  and  Component  Commands 

(1)  Requirements  Review.  The  CINCs  and  Commander,  US 
Element,  NORAD,  will  review  and  comment  on  all  ACAT  I/LA  and  JROC 
special  interest  documents  that  are  validated  and  approved  by  the  JROC. 
CINCs  also  are  provided  the  opportunity  to  review  and  comment  on  ACAT 
II  and  below  documents  during  the  J2/J6  certification  process. 

(2)  CINC-Generated  Mission  Need  Statements.  The  CINCs  and 
Commander,  US  Element,  NORAD,  will  forward  all  CINC-generated  MNSs 
to  the  JROC  for  initial  0-6  level  review  as  outlined  in  Enclosure  B. 
USSOCCOM  will  retain  validation  and  approval  authority  for  all  SOCOM 
MNSs  that  result  in  potential  ACAT  II  and  below  programs  in  accordance 
with  reference  c,  section  167.  The  preferred  method  for  CINC  MNS 
generation  is  for  the  CINCs  to  identify  their  mission  needs  to  the 
responsible  Service  component  commander  or  appropriate  DOD  agency 
(references  n  and  o) .  The  component  or  agency  will  then  coordinate  the 
definition  and  documentation  activities  through  their  sponsoring  Services 
or  agency  requirements  system  and  keep  the  CINCs  apprised  of  the 
status  of  the  MNS. 
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(a)  JROC  approval.  If  the  0-6  review  recommends  a  JPD  of 
“joint  interest”  or  “joint,”  then  the  MNS  will  complete  flag  level  review  and 
will  be  forwarded  to  the  JROC  for  validation  and  approval  as  outlined  in 
Enclosures  B  and  C. 

(b)  CINC  approval.  If  the  0-6  Review  recommends  a  JPD  of 
“independent,”  then  the  MNSs  will  be  returned  to  the  sponsoring  CINC 
for  validation  and  approval.  Upon  approval,  the  CINC  will  forward  the 
MNS  to  the  appropriate  Service  or  agency  designated  office  responsible 
for  the  requirements  generation  system,  which  will  forward  the  MNS  to 
the  component  acquisition  executive. 

(3)  CINC  Field  Assessments  (CFA).  The  purpose  of  a  CFA  is  to 
provide  a  deployed /employed  CINC  a  rapid,  tailored  analysis  in  response 
to  an  emergent  threat  capability  and  to  meet  urgent  priority  information 
needs  about  fielded  US  force  or  system  capabilities  and/or  vulnerabilities 
involving  more  than  one  service.  The  CFA  process  and  submission 
criteria  are  described  in  reference  f. 

(4)  Joint  Staff  Assistance.  Joint  Staff  assistance  may  be  needed  to 
support  a  CINC  in  the  development  of  a  mission  need  or  in  determining  if 
a  CINC-generated  MNS  is  redundant  to  a  validated  MNS  or  one  under 
development.  J8  RAD  will  be  the  POC  on  the  Joint  Staff  for  the  CINCs  to 
contact  for  assistance.  Joint  Warfighting  Capabilities  Assessment 
(JWCA)  teams  (reference  e)  and  Joint  Staff  functional  area  experts  can  be 
designated  to  assist  during  the  definition  and  documentation  phase  of 
MNS  development.  The  intent  is  not  to  have  the  Joint  Staff  write  the 
requirements  document,  but  to  see  that  responsible  DOD  components 
are  identified  to  provide  assistance.  If  required,  the  JROC  will  assign  a 
DOD  component  as  lead  for  CINC-generated  MNS. 

(5)  Senior  Warfighter  Forum  (SWARF).  The  JROC  will  address 
CINC  issues  and  recommendations  on  the  adequacy  of  requirements 
generation  and  investment  strategies  through  the  currently  established 
JROC  trips,  and  the  requirements  generation,  acquisition,  and  PPBS 
processes.  If  a  CINC  identifies  a  joint  requirements  issue  or  resource 
mismatch  they  can  forward  a  request  to  the  JROC  to  convene  a  SWARF. 
The  SWARF  is  a  JROC-directed  forum  used  to  organize,  analyze, 
prioritize,  and  build  joint  consensus  on  a  complex  resource  and 
requirements  issue  for  JROC  approval.  The  JROC  tasking  memorandum 
will  identify  the  SWARF  lead,  specific  issue  to  be  addressed,  fiscal 
guidelines,  assignment  of  the  appropriate  acquisition  and  technical 
expertise  to  frame  issue,  and  timeline  to  report  recommendation(s).  The 
JROC  will  assign  CINCs  to  lead  SWARFs  according  to  their  missions  and 
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responsibilities.  The  SWARF  lead  will  brief  the  recommendation(s)  to  the 
JROC. 

(6)  United  States  Special  Operations  Command  (USSOCOM). 
Congress  has  given  USCINCSOC  specific  title  10  authority  with  a  unique 
major  force  appropriation  category  (reference  c,  section  167).  Therefore, 
USCINCSOC  can  establish,  validate,  and  approve  USSOCOM 
requirements  and  budget  for  AC  AT  II  and  below  programs. 

(7)  United  States  Atlantic  Command  (USACOM) 

(a)  Joint  Experimentation.  USCINCACOM  is  designated  the 
Executive  Agent  for  conducting  joint  warfighting  experimentation. 
USCINCACOM  is  responsible  to  the  CJCS  for  creating  and  refining  future 
Joint  Warfighting  Concepts  and  integration  of  Service  efforts  in  support 
of  JV2010  and  future  CJCS  Joint  Warfighting  Visions.  USCINCACOM 
will  conduct  joint  experimentation  to  explore,  demonstrate,  and  evaluate 
joint  warfighting  concepts.  Experimentation  will  identify  the 
breakthrough  warfighting  capabilities  necessary  to  achieve  JV2010  and 
future  visions.  Recommendations  from  joint  experimentation  having 
potential  materiel  solutions  will  be  forwarded  by  USCINCACOM  to  the 
JROC  for  review.  These  recommendations  could  be  the  basis  to  conduct 
a  joint  mission  need  analysis  that  could  lead  to  the  development  of  a 
MNS  or  CRD. 

(b)  Interoperability.  USCINCACOM  will  serve  as  the  Chairman's 
advocate  for  joint  warfighting  interoperability.  USACOM  will  provide  the 
warfighter  perspective  during  the  development  of  joint  operational 
concepts  to  ensure  that  joint  forces  have  interoperable  systems. 

USACOM  will  support  the  Chairman  in  the  following  areas: 

(1)  USACOM  will  coordinate  with  the  Joint  Staff  J6  and 
ASD(C3I),  co-chairs  of  the  Joint  Operational  Architecture  Working 
Group,  along  with  the  CINCs  to  continue  development  of  the  C4ISR  Joint 
Operational  Architecture  (JOA).  The  objective  of  the  C4ISR  JOA  is  to 
enable  joint  force  commanders  and  forces  to  achieve  interoperable, 
integrated  joint  military  operations  employing  the  operational  concepts  of 
Joint  Vision  2010. 

(2)  USACOM  will  comment  during  the  requirements  staffing 
process  on  the  adequacy  of  CRD  and  ACAT  I/LA  ORD  Interoperability 
KPPs.  The  comments  will  provide  the  warfighter  perspective  on  the 
adequacy  of  interoperability  as  addressed  in  the  CRD  or  ORD.  For  ACAT 
I/LA.  and  JROC  special  interest  ORDS  and  CRDs,  USACOM  will  have  the 
opportunity  to  comment  on  unresolved  interoperability  issues  at  the 


B-7 


Enclosure  B 


CJCSI  3170. 01A 
10  August  1999 

JROC.  USACOM  will  be  available  to  comment  on  interoperability  issues 
that  are  forwarded  to  the  DAB  by  the  JROC. 

(3)  USACOM  can  comment  on  interoperability  issues  for 
AC  AT  II  and  below  programs  identified  during  the  Joint  Staff  J6 
interoperability  certification  process. 

e.  Defense  Agencies.  Defense  agencies  may  be  tasked  to  manage 
acquisition  programs.  The  agencies  may  develop  their  own  MNSs  as  a 
DOD  component  or  be  asked  to  manage  programs  initiated  by  the  CINCs 
or  Services. 

3.  Procedures 


a.  Standardization  of  Document  Formats.  Requirements  documents 
(MNSs,  CRDs,  and  ORDs)  will  be  uniform  across  all  DOD  organizations 
and  apply  to  all  acquisition  categories.  This  standardization  instills 
discipline  in  the  process  and  provides  both  the  validation  and  approval 
authorities,  and  the  acquisition  management  system,  with  efficient  and 
consistent  information  to  use  in  reviews,  certifications,  and  decision 
deliberations.  However  for  programs  that  do  not  go  before  the  JROC, 
DOD  Component  ORD  validation  and  approval  authorities  can  amplify 
the  format  on  a  case-by-case  basis  to  support  their  decision  process  (e.g., 
Mapping,  Charting,  and  Geodesy  Support  is  not  required  or  inclusion  of 
expanded  information  within  a  specific  area  of  operation).  The  MNS, 

CRD  and  ORD  formats  are  found  in  Appendix  A  to  Enclosure  C, 

Appendix  A  to  Enclosure  D,  and  Appendix  A  to  Enclosure  E,  respectively. 

b.  Document  Submission.  All  MNSs,  CRDs,  and  ORDs  that  go  to  the 
JROC  will  be  submitted  to  J-8  RAD  through  the  DOD  component  JROC 
coordination  organization.  The  document  shall  be  the  DOD  component 
0-6  level  coordinated  position.  The  document  shall  be  forwarded  with  a 
cover  letter  identifying  the  document,  date,  any  schedule  drivers,  and  a 
working  level  POC.  Also,  an  executive  summary  of  the  analysis 
supporting  the  development  of  the  document  and  specific  analysis  used 
in  CRD  /  ORD  KPP  determination  will  be  provided  with  the  draft 
document.  All  documents  going  through  the  review  process  are 
considered  draft  and  do  not  require  a  formal  signature  until  after  JROC 
validation  and/or  approval. 

(1)  Format.  The  submission  shall  be  an  electronic  copy  in  MS 
Word  Version  6.0  or  higher  and  one  hard  copy. 

(2)  Joint  C4I  Program  Assessment  Tool  (JCPAT).  All  ACAT  II  and 
below  MNS/ORDs  and  CRDs  are  currently  submitted  by  electronic  copy 
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to  the  JCPAT  database  to  conduct  the  J2/J6  certification  process.  (The 
JCPAT  SIPRNET  website  URF  address  is  http://206.36.228.76).  J8  and 
DISA  are  developing  a  plan  to  have  all  ACAT  level  documents  submitted 
via  the  JCPAT.  The  JCPAT  will  be  able  to  be  utilized  by  DOD 
components  to  submit  documents,  comment  for  O-6/flag  reviews, 
search  for  historical  information  and  track  current  status  of  documents. 
J8  will  provide  formal  notification  via  JROCSM  to  initiate  this  change  in 
document  submission  for  JROC  review  and  the  procedures  for  using  the 
database. 

c.  Formal  Document  Review  Process.  Once  a  document  enters  the 
formal  JROC  0-6  /Flag  review  process,  it  will  be  staffed  to  all  Services, 
CINCs,  Joint  Staff,  and  appropriate  DOD  agencies  for  review  and 
comment.  It  is  understood  that  0-6  level  staffing  does  not  necessarily 
result  in  the  final  Service  position.  Flag-level  endorsement  of  0-6  level 
comments  is  neither  required  nor  desired.  Comments  should  be 
identified  as  either  critical,  substantive,  or  administrative.  Convincing 
support  for  critical  and  substantive  comments  will  be  provided  in  a 
Comment/ Justification  format.  Definitions  are  provided  below: 

CRITICAL.  A  critical  comment  indicates  nonconcurrence  with  the 
document,  for  both  the  0-6  and  flag  review,  until  the  comment  is 
satisfactorily  resolved.  If  the  nonconcurrence  is  not  resolved  after  flag 
review  the  document  will  proceed  to  the  Joint  Requirements  Panel  (JRP). 
The  briefing  to  the  JRP  will  outline  the  unresolved  issue  (s). 

SUBSTANTIVE.  A  substantive  comment  is  provided  because  a 
section  in  the  document  appears  to  be  or  is  potentially  unnecessary, 
incorrect,  misleading,  confusing,  or  inconsistent  with  other  sections. 

ADMINISTRATIVE.  An  administrative  comment  corrects  what 
appears  to  be  a  typographical,  format,  or  grammatical  error.  The 
following  review  process  steps  apply  to  MNSs,  CRDs,  and  ORDs  as 
depicted  in  Figure  4. 
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Figure  4.  JROC  Formal  Review  Process 


Step  (1)  Document  Submittal.  The  sponsoring  DOD  component 
submits  a  draft  document  in  accordance  with  paragraph  3b. 


Step  (2)  0-6  Review.  J-8/RAD  will  review  and  verily  the  format  for 
accuracy  and  completeness.  J8  will  staff  the  draft  document  via  JROC 
staff  memorandum  (JROCSM)  for  CINC,  Service,  Joint  Staff,  and 
appropriate  DOD  agency  0-6  level  review.  The  suspense  date  will 
normally  be  35  days  from  transmittal  date.  This  review  will  include 
initial  intelligence  supportability  (J-2/DIA),  munitions  interoperability/ 
insensitivity  certification  (J-4),  and  C4  interoperability  certification  (J-6). 


Step  (3)  Incorporate  0-6  comments.  J-8  will  compile  and  forward 
all  comments  back  to  the  sponsoring  DOD  component  via  JROCSM  for 
incorporation  or  revision  as  necessary.  Following  incorporation  or 
revision  of  0-6  level  review  comments,  the  sponsor  should  forward  the 
draft  document  to  J-8/RAD  for  flag-level  review.  The  sponsor  will 
provide  a  correlation/resolution  matrix  delineating  the  critical  and 
substantive  comments,  and  the  results  of  the  Intelligence  and 
Interoperability  certification  received  during  0-6  level  review  and  actions 
taken.  For  ease  of  review  highlight  the  changes  made  to  the  document 
with  vertical  bars  in  the  margin  or  line-in/line-out  format. 
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Step  (4)  Flag  level  review.  This  review  will  include  final  intelligence 
supportability  certification  (J2/DIA),  munitions  interoperability/ 
insensitivity  certification  (J-4),  and  C4  interoperability  certification  (J-6). 
The  suspense  date  for  providing  comments  and/or  concurrence  will  be 
21  days  from  transmittal  date. 

Step  (5)  Incorporation  of  Flag  comments  and  brief  preparation. 
Upon  completion  of  flag  level  review  J-8/RAD  will  compile  and  forward  all 
comments  back  to  the  sponsor  via  JROCSM  for  final  incorporation  or 
revision.  Once  sponsor  has  incorporated  flag-level  review  changes,  and 
has  developed  the  JROC  briefing,  J-8  RAD  will  schedule  JROC  briefings 
with  the  JROC  Secretariat. 

d.  JROC  Briefing  Format  and  Schedule.  Briefings  for  the  Joint 
Requirements  Panel  (JRP),  Joint  Requirements  Board  (JRB),  and  Joint 
Requirements  Oversight  Council  (JROC)  will  be  prepared  in  accordance 
with  reference  q.  The  DOD  component  will  provide  the  updated  draft 
document  and  briefing  slides  48  hours  prior  to  the  JRP  brief.  The  JROC 
should  convene  at  least  30  days  prior  to  the  DAB  or  DOD  CIO  review  to 
allow  adequate  time  for  Integrated  Product  Team  (IPT)  review. 

4.  Automated  Information  Systems  (AIS).  Automated  Information 
Systems  are  a  combination  of  computer  hardware  and  software,  data,  or 
telecommunications  that  performs  functions  such  as  collecting, 
processing,  transmitting,  and  displaying  information.  Excluded  are 
computer  resources,  both  hardware  and  software,  that  are  physically 
part  of,  dedicated  to,  or  essential  in  real  time  to  the  mission  performance 
of  weapon  systems.  Given  the  potential  joint  nature  of  Automated 
Information  Systems  all  AIS  MNS/ORDs  will  be  submitted  through  the 
Joint  Staff  J8  to  determine  if  JROC  review  is  warranted.  Figure  5 
outlines  the  steps  for  determination  of  level  of  AIS  coordination  and 
review. 
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Figure  5.  AIS  review  process 


Step  (1)  The  sponsoring  DOD  component  submits  draft  AIS 
MNS/ORD  document  into  JCPAT  database  or  J8  RAD. 

Step  (2)  J8  RAD  accesses  the  database  and  reviews  document.  If 
document  meets  MDAP  and/or  MAIS  expenditure  criteria  or  has  been 
previously  designated  JROC  special  interest  the  document  will  be  staffed 
through  normal  JROC  process  for  validation  and  approval. 


Step  (3)  All  other  AIS  documents  will  be  forwarded  to  the  Service 
JRP  members  for  a  7-day  review  to  determine  whether  the  program  has 
joint  and/or  Service  impacts. 

Step  (4)  If  no  joint  or  service  issues  are  identified  the  J8  will 
return  the  MNS/ORD,  via  JROCSM,  for  validation  and  approval  by  the 
AIS  sponsor. 

Step  (5)  If  J8/JRP  members  identify  any  joint  or  service  issue(s) 
the  document  will  be  staffed  for  formal  JROC  0-6  level  review. 

Step  (6)  Upon  completion  of  0-6  review  the  sponsor  will  provide  an 
information  briefing  on  the  MNS/ORD  to  include  comments  received 
from  the  0-6  review.  The  JRP  will  determine  if  the  MNS/ORD  should  be 
considered  for  designation  as  JROC  special  interest. 


Step  (7)  If  the  JRP  does  not  recommend  designation  as  JROC 
special  interest  the  document  will  be  returned,  via  JROCSM,  to  the 
sponsor  for  validation  and  approval. 
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Step  (8)  If  the  JRP  recommends  MNS/ORD  designation  of  JROC 
special  interest  the  document  will  staffed  for  flag  review  and  the  normal 
JROC  briefing  cycle  for  validation  and  approval. 
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ENCLOSURE  C 

MISSION  NEED  STATEMENT  GENERATION  PROCESS 


1.  Mission  Need  Statements  (MNS).  The  MNS  is  a  non-system-specific 
statement  of  operational  capability  need  written  in  broad  operational 
terms.  The  four  phases  of  the  MNS  generation  process  are  depicted  in 
Figure  6. 
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Figure  6.  MNS  Generation  Process 


a.  MNS  Definition  Phase.  Identification  of  deficiencies  and 
opportunities  is  a  continuing  process  and  normally  begins  with  a  review 
of  the  latest  National  Security  Policy,  National  Military  Strategy,  Defense 
Planning  Guidance  (DPG),  CINC  Integrated  Priority  List  (IPL),  Joint 
Intelligence  Guidance  (if  appropriate),  and  projected  threats.  This 
information  should  be  incorporated  into  an  assessment  of  the  current 
and  projected  capability  to  accomplish  assigned  missions.  This 
evaluation  is  best  accomplished  by  a  Mission  Area  Analysis  (MAA) . 
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(1)  Mission  Area  Analysis  (MAA).  The  MAA,  or  equivalent  DOD 
component  procedures,  should  identify  capability  deficiencies  and  the 
time  frame  that  these  deficiencies  will  exist.  The  MAA  should  use  a 
“strategy-to-task”  methodology  (e.g.,  National  Military  Strategy  to 
individual  mission  tasks)  to  identify  the  operational  and  support  tasks 
needed  to  meet  mission  objectives. 

(2)  Mission  Need  Analysis  (MNA).  The  MNA,  or  equivalent  DOD 
component  procedures,  should  be  accomplished  to  evaluate  the  identified 
deficiencies  using  a  task-to-need  methodology  to  identify  mission  needs. 
This  analysis  must  look  across  DOD  component  boundaries  for 
solutions.  The  (JCPAT)  database  can  be  utilized  to  search  for  draft  and 
validated  MNSs  to  ensure  unnecessary  duplication  of  effort  is  avoided. 
The  process  may  also  begin  with  the  identification  of  opportunities  to 
exploit  technology  breakthroughs  that  provide  new  capabilities  that 
address  established  needs,  reduce  ownership  costs,  or  improve  the 
effectiveness  of  current  equipment  and  systems.  Mission  needs  analysis 
should  identify  the  time-based  nature  of  the  need  and  identify  the 
specific  time  frame  the  need  is  expected  to  exist.  If  the  need  is  to  meet  a 
current  operational  deficiency  the  MNA  should  state  so.  If  the  timing  of 
the  need  is  based  on  future  threats  or  other  activities  (such  as  the 
planned  retirement  of  an  existing  capability),  these  should  be  identified. 

(a)  Non-materiel  solutions.  Non-materiel  solutions  include 
changes  in  Doctrine,  Organization,  Training,  Leadership,  and  Personnel 
(DOTLP).  If  the  need  can  be  fulfilled  by  a  non-materiel  solution,  the 
sponsor  should  refer  it  to  the  appropriate  DOD  component  for  action. 

(b)  Materiel  solutions.  If  the  MNA  determines  that  a  materiel 
solution  should  be  pursued,  the  deficiencies  or  technological 
opportunities  should  be  translated  into  a  MNS  expressed  in  broad 
operational  terms.  When  a  material  solution  is  pursued  non-materiel 
(DOTLP)  changes  will  be  required  to  support  the  program  through 
development  and  fielding. 

(3)  Joint  Mission  Area  Analysis  and  Mission  Need  Analysis.  During 
the  MAA/MNA  process,  if  initial  analysis  indicates  potential  impact  to  the 
joint  community  the  appropriate  DOD  components  must  be  involved. 

The  only  difference  between  a  MAA/MNA  and  Joint  MAA/MNA  is  the 
scope  and  participation  required  to  adequately  conduct  the  analysis  and 
assessment.  The  intent  of  JMAA/JMNA  is  to  have  joint  participation 
(CINC)  during  the  initial  assessments.  CINCs  should  be  contacted  to 
participate  during  the  working  group  meetings  and  can  use  their  Service 
components  to  reach  back  into  service  generated  assessments.  The  lead 
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DOD  component  for  Joint  MAA/MNA  development  is  responsible  to 
ensure  proper  joint  participation  and  documentation  of  all  analysis  to 
support  MNS  development  and  documentation.  Appendix  B  of  this 
enclosure  outlines  a  sample  organizational  structure  and  template  to 
conduct  a  Joint  MNA. 

b.  MNS  Documentation  Phase.  When  a  DOD  component  has 
determined  that  a  materiel  solution  should  be  pursued,  a  MNS  will  be 
prepared.  The  MNS  sponsor  shall  coordinate  the  draft  document  with 
the  applicable  DOD  components  before  forwarding  to  the  validation 
authority  for  formal  review  and  coordination.  If  an  existing  JROC  or 
DOD  component  validated  MNS  covers  the  mission  need  a  new  MNS  will 
not  be  required.  The  MNS  originator  identifies  what  potential  AC  AT  level 
the  program  may  result  in  and  whether  it  is  a  potential  MDAP  or  MAIS. 
The  document  should  use  the  format  as  outlined  in  appendix  A  of  this 
enclosure  and  be  no  longer  than  five  pages. 

c.  MNS  Validation  Phase.  Validation  of  a  MNS  confirms  that  the 
mission  need  exists  and  cannot  be  satisfied  by  a  non-materiel  solution. 

As  a  minimum,  the  validation  authority  reviews  the  MNS,  confirms  that  a 
non-materiel  solution  is  not  feasible,  and  assesses  the  Joint  Service 
potential.  CINC  generated  MNSs  will  be  addressed  per  enclosure  B. 
Validation  is  conducted  by  an  authority  other  than  the  user  and  may 
take  place  at  different  organizational  levels  depending  on  MNS 
origination  and  potential  program  AC  AT  level. 

(1)  JROC  Validation.  JROC  validation  begins  with  the  formal 
review  of  the  document  for  all  potential  ACAT  I/LA  and  identified  JROC 
Special  Interest  MNSs.  The  first  step  in  obtaining  validation  is 
submission  of  the  draft  document  for  formal  review  as  outlined  in 
enclosure  B.  The  sponsor  will  also  provide  an  executive  summary  that 
describes  the  analysis  process  used  to  develop  the  draft  document. 

(2)  DOD  Validation.  DOD  component  heads  (or  as  delegated)  will 
validate  their  own  potential  ACAT  II  and  below  MNSs  not  identified  as 
JROC  special  interest  or  statement  of  need  as  identified  through  analysis 
and  documented  in  the  product  of  the  Mission  Need  Analysis. 

(3)  Joint  Potential  Review/Designation.  The  MNS  sponsor  will 
assess  the  joint  potential  for  the  MNSs  as  part  of  the  initial  validation 
process  by  coordinating  the  MNS  with  the  Services.  The  sponsoring  DOD 
component  will  assign  a  Joint  Potential  Designation  (JPD)  of 
independent,  joint  interest,  or  joint  (as  defined  in  the  Glossary  of  this 
instruction)  based  on  the  input  received  during  Service  coordination. 
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d.  MNS  Approval  Phase 

(1)  JROC  approval.  The  approval  authority  for  all-potential  AC  AT 
I/IA  and  identified  JROC  special  interest  MNSs  is  the  JROC.  The  JROC 
will  make  a  recommendation  on  the  joint  potential  designator  (JPD)  and 
the  lead  Service  or  agency  for  programs  involving  more  than  one  DOD 
component.  The  approved  MNS  and  appropriate  recommendations  will 
be  forwarded,  via  JROCM,  to  USD  (A&T)  for  consideration  during  the 
DAB,  or  to  ASD  (C3I)  for  consideration  during  the  DOD  CIO  review.  The 
JROC  will  determine  whether  CRD  development  is  appropriate  when  they 
approve  the  MNS.  The  JROC  may  also  make  recommendations  to 
USCINCACOM  for  Joint  Experimentation  to  facilitate  concept 
development  and  clarify  joint  interoperability  needs. 

(2)  DOD  component  approval.  The  approval  authority  for  potential 
ACAT  II  and  below  MNSs  is  the  Chief/ Director  of  a  DOD  component  who 
will  forward  the  MNS  to  the  component  acquisition  authority. 

e.  Designation  of  Lead  DOD  Component.  Joint  programs  require  the 
designation  of  a  lead  DOD  component  by  the  Milestone  Decision 
Authority  (MDA) .  The  MDA  makes  the  decision  based  on  the 
recommendation  of  the  JROC  for  potential  MDAP  and  MAIS  programs  or 
of  the  Chief  /Head  of  the  DOD  component  for  all  other  programs.  The 
responsibilities  of  the  lead  component  are  described  in  reference  b,  part 
3,  and  subparagraph  3. 3. 5. 3,  “Joint  Program  Management.”  The  JROC 
will  include  its  lead  Service  or  agency  recommendation  to  USD  (A&T)  for 
approved  ACAT  I  MNS  with  joint  potential  and  ASD(C3I)  for  appropriate 
ACAT  IA  MNS.  DOD  components  lacking  an  acquisition  structure  and 
unable  to  obtain  Service  support  (e.g.,  unified  commands  [other  than 
USSOCOM],  Joint  Staff,  and  some  Defense  agencies)  may  forward 
potential  ACAT  II  and  below  validated  and  approved  MNSs  to  the  JROC. 
The  JROC  will  coordinate  designation  of  a  lead  Service  or  agency  and 
forward  the  MNS  to  that  Service's  MDA  for  action.  A  DOD  agency  may  be 
designated  as  lead  component. 

f.  MNS  Retirement.  In  the  event  a  JROC  approved  MNS  is  superseded 
or  the  mission  need  no  longer  exists,  a  MNS  can  be  brought 

to  the  JROC  for  formal  retirement.  Requests  for  retiring  a  MNS  with 
justification  should  be  forwarded  to  the  JROC  Secretariat  for  staffing. 
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APPENDIX  A  to  ENCLOSURE  C 

MISSION  NEED  STATEMENT  FORMAT 

MISSION  NEED  STATEMENT 
FOR 
TITLE 

Potential  ACAT 

DATE 

1.  Defense  Planning  Guidance  Element.  Identify  the  major  program 
planning  objective  or  section  of  the  Defense  Planning  Guidance  to  which 
this  need  responds.  Also  reference  the  Joint  Intelligence  Guidance,  DOD 
Strategic  Plan  (Quadrennial  Defense  Review),  and  Military  Department 
long-range  investment  plans,  if  applicable. 

2.  Mission  and  Threat  Analyses.  Identify  and  describe  the  mission  need 
or  deficiency.  Define  the  need  in  terms  of  mission,  objectives,  and 
general  capabilities.  Do  not  discuss  the  need  in  terms  of  equipment  or 
system-specific  performance  characteristics.  Discuss  the  Defense 
Intelligence  Agency  (DIA) -validated  threat  to  be  countered  as  well  as  the 
projected  threat  environment  and  the  shortfalls  of  existing  capabilities  or 
systems  in  meeting  these  threats.  Comment  on  the  timing  of  the  need 
and  the  general  priority  of  this  need  relative  to  others  in  this  mission 
area. 

3.  Nonmateriel  Alternatives.  Discuss  the  results  of  the  mission  needs 
analysis.  Identify  any  changes  in  US  or  allied  doctrine,  operational 
concepts,  tactics,  organization,  and  training  that  were  considered  in  the 
context  of  satisfying  the  deficiency.  Describe  why  such  changes  were 
judged  to  be  inadequate. 

4.  Potential  Materiel  Alternatives.  Identify  known  systems  or  programs 
addressing  similar  needs  that  are  deployed  or  are  in  development  or 
production  by  any  of  the  Services,  Agencies,  or  allied  nations.  Discuss 
the  potential  for  inter-Service  or  allied  cooperation.  Indicate  potential 
areas  of  study  for  concept  exploration  including  the  use  of  existing  US  or 
allied  military  or  commercial  systems  including  modified  commercial 
systems  or  product  improvements  of  existing  systems.  Do  not  evaluate 
these  alternatives. 

5.  Constraints.  Describe,  as  applicable,  key  boundary  conditions  related 
to  infrastructure  support  that  may  impact  on  satisfying  the  need: 
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available  facilities;  logistics  support;  transportation;  global  geospatial 
information  and  services  support;  manpower,  personnel,  and  training 
constraints;  command,  control,  communications,  and  intelligence 
interfaces;  security;  standardization  and  interoperability  within  DOD 
components,  North  Atlantic  Treaty  Organization  (NATO),  other  allies  and 
friendly  nations  as  well  as  U.S.  government  agencies  and  non¬ 
government  organizations.  Address  the  operational  environments 
(including  conventional;  initial  nuclear  weapon  effects;  nuclear, 
biological,  and  chemical  contamination  (NBCC),  electronic, 
electromagnetic  and  natural)  in  which  the  mission  is  expected  to  be 
accomplished.  Define  the  level  of  desired  mission  capability  in  these 
environments. 

6.  Joint  Potential  Designator.  Indicate  the  Joint  Potential  Designator 
established  through  the  validation  process. 


For  Automated  Information  Systems  (AIS)  only. 

For  AIS  programs  the  following  additional  information  should  be 
incorporated  in  the  MNS  format: 

1 .  Defense  Planning  Guidance  Element:  Describe  how  the  mission  need 
relates  to  the  OSD  Principal  Staff  Assistant's  (PSAs),  DoD  Chief 
Information  Officer,  and  the  DoD  component  strategic  planning. 

2.  Mission  and  Threat  Analyses:  Describe  the  functional  area  or  activity's 
current  organization  and  operational  environment,  with  emphasis  on 
existing  functional  processes,  including  the  concept  of  operation  of  the 
existing  functional  processes,  procedures,  and  capabilities.  Describe  the 
shortfalls  of  existing  capabilities. 

a.  Describe  quantitative  benchmarks  of  process  performance  in  terms 
of  speed,  productivity,  and  quality  of  outputs  where  comparable 
processes  exist  in  the  public  or  private  sectors. 

b.  Describe  whether  the  function  to  be  supported  by  the  information 
technology  should  be  performed  by  the  organization  that  has  identified 
the  need  or  whether  the  function  could  be  performed  by  a  private  sector 
source. 
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APPENDIX  B  TO  ENCLOSURE  C 
Notional  Joint  Mission  Need  Analysis  Working  Groups 
Primary  Working  Groups: 

(1)  Operations  &  Threat:  Define  Mission  Analysis,  Threat  Analysis 
and  Prepare  Capabilities  Assessment 

(2)  Programs  &  Technology:  Define  Material  Baseline  and  Prepare 
Concept  Assessment 

Supporting  Working  Groups: 

(1)  Policy:  Define  Policy  and  Critical  Issues  Baseline 

(2)  Programs  &  Resources:  Examine  Current /Future  Resource 
Trends  and  Forecasts  and  Prepare  Resources  Assessment 


Joint  Mission  Need  Analysis  Working  Group 
Mission  and  Task  List 

Operations  &  Threat  WG:  Define  Mission  Analysis,  Threat  Analysis  and 

Prepare  Capabilities  Assessment 

■  Identify  list  of  known  operational  deficiencies 

■  Identify  list  of  required  operational  capabilities 

■  Identify  list  of  deficiencies  in  meeting  required  operational  capabilities 

■  Identify  current  and  near-term  system/ device  attributes,  parameters, 
capabilities  and  characteristics 

■  Identify  list  of  potential  nonmaterial  alternatives  to  satisfy  deficiencies 
in  operational  capabilities 

■  Define  Threat 

■  Conduct  Threat  Analysis 

■  Consider  doctrine,  strategy,  tactics,  operational  factors,  related 
lessons  learned  and  warplans  inputs 

■  Conduct  Mission  Analysis  of  required  operational  capabilities, 
including  nonmaterial  alternatives  and  potential  material  solutions 

■  Associate  Threat  Analysis  with  Mission  Analysis 

■  Review  draft  MNS  and  compare  known  operational  capabilities  and 
deficiencies,  if  available,  with  those  generated  in  Mission  Analysis 
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■  Coordinate  results  w/  Programs  &  Technology's  technological 
alternatives  to  define  gaps  requiring  a  material  solution 

■  Prepare  Capability  Assessment  of  current  potential  solutions 

Programs  &  Technology  WG:  Define  Material  Baseline  and  Prepare 

Concept  Assessment 

■  Identify  list  of  all  existing  technological  alternatives 

■  Identify  list  of  emerging  technology 

■  Identify  list  of  collateral  technology  (i.e.  Allies) 

■  Review  any  planned  applicable  ATDs  &  ACTDs 

■  Consider  Threat  and  Mission  Analysis  (coord  w/  Operations  &  Threat) 

■  Consider  nonmaterial  alternatives  (coord  w/  Operations  &  Threat) 

■  Select  master  list  of  candidate  technologies  for  potential  alternatives 

■  Review  draft  MNS  and  compare  potential  technological  alternatives,  if 
available,  to  master  list 

■  Prepare  Concept  Assessment  of  potential  technological  solutions  to 
the  extent  required  to  demonstrate  that  there  are  solutions  available, 
not  to  develop  proponency  for  any  specific  alternative  (s). 

Policy  WG:  Define  Policy  and  Critical  Issues  Baseline 

■  Outline  associated  Policies  and  Directives 

■  Identify  list  of  associated  critical  operational  issues  that  affect  MNS 
development 

■  Refine  list  of  critical  issues  to  those  that  need  to  be  addressed  during 
MNS  development 

■  Support  preparation  of  Capabilities  and  Concept  Assessments  (coord 
w/  Operations  &  Threat) 

Programs  &  Resources  WG:  Examine  Current/ Future  Resource  Trends 

and  Forecasts  and  Prepare  Resources  Assessment 

■  Identify  R&D,  Acquisition  and  Procurement  periods  of  potential 
material  solutions 

■  Examine  timeframes  of  current  budget  cycles  and  forecasts  at 
associated  intervals:  2003,  2006,  2010,  2015,  2020 

■  Identify  potential  overarching/ specific  resource  constraints 

■  Identify  potential  timing  and  priority  issues 

■  Estimate  resources  required  to  implement  nonmaterial  solutions  to 
operational  deficiencies 

■  Estimate  funding  and  program  characteristics  for  generic  concepts 
(coord  w/  Programs  &  Technology) 
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■  Prepare  Resources  Assessment  including  comparison  of 

material /nonmaterial  solution  alternatives  in  support  of  Capabilities 
and  Concepts  Assessments  (coord  w/  Operations  &  Threat) 


Working  Group  MNS  Writing  Tasks 

Section  1 :  Defense  Planning  Guidance  Element 

■  Policy 

Section  2:  Mission  and  Threat  Analysis 

■  Para  A:  Mission 

■  Operations 

■  Para  B:  Threat 

■  Threat 

■  Para  C:  Current  Deficiencies  -  Shortfalls 

■  Operations 

■  Programs  &  Technology 

■  Para  D:  Timing  and  Priority 

■  Operations 

■  Programs  &  Technology 

■  Policy 

■  Programs  &  Resources 

Section  3:  Nonmaterial  Alternatives 

■  Operations 

■  Programs  &  Technology 

Section  4:  Potential  Material  Alternatives 

■  Operations 

■  Programs  &  Technology 

■  Programs  &  Resources 

Section  5:  Constraints 

■  Para  A:  Overarching  Constraints 

■  Operations 

■  Programs  &  Technology 

■  Programs  &  Resources 

■  Para  B:  Logistics 

■  Operations 

■  Para  C:  Survivability 

■  Operations 

■  Para  D:  Operational  Environment 
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■  Operations 

■  Threat 

Section  6:  Joint  Potential  Designator 
■  Operations 
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ENCLOSURE  D 

CAPSTONE  REQUIREMENTS  DOCUMENT  GENERATION  PROCESS 


1.  Capstone  Requirements  Document  (CRD).  The  CRD  captures  the 
overarching  requirements  for  a  mission  area  that  forms  a  family-of- 
systems  (FoS)  (e.g.  space  control,  theater  missile  defense,  etc.)  or  System- 
of-Systems  (SoS)  (e.g.  national  missile  defense).  CRDs  are  intended  to 
guide  the  DOD  components  in  developing  mission  needs  and  operational 
requirement  documents  for  future  and  legacy  systems.  This  will  facilitate 
development  of  interoperable  systems  through  validated  performance 
based  overarching  capabilities  described  in  the  CRD.  CRDs  are 
inherently  developed  for  a  joint  mission  area;  accordingly,  requirements 
for  a  CRD  must  reflect  the  needs  of  the  joint  force  commander.  A  CRD  is 
appropriate  when  a  mission  area  requires  more  than  one  ORD  and  when 
systems  are  developed  by  multiple  DOD  components. 


a.  Applicability.  The  requirements  identified  for  a  CRD  apply  to  any 
DOD  component  involved  in  identifying  and  further  articulating 
requirements  for  all  MNS/ORDs  that  fall  under  the  CRD.  The  four 


Figure  7.  CRD  Generation  Process 
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(1)  CRD  Initiation.  CRD  initiation  is  through  JROC  direction.  A 
DOD  component  may  recommend  initiation  of  a  CRD  to  the  JROC  during 
MNS  validation  and  approval  or  USACOM  may  recommend  initiation  of  a 
CRD  as  an  output  from  Joint  Experimentation.  CRDs  will  not  be 
developed  for  a  mission  need  with  limited  scope  or  if  the  mission  need 
falls  under  an  existing  CRD  or  one  in  development. 

(2)  JROC.  The  JROC  will  designate  a  CRD  lead  via  JROCM.  In  the 
JROCM,  the  JROC  will  provide  guidance  to  the  CRD  lead  describing 
specific  actions  and  timelines  for  CRD  development.  The  CRD  lead  is 
responsible  for  developing,  drafting,  and  sponsoring  the  CRD  through  the 
JROC  validation  and  approval  process.  The  CRD  lead  will  identify  all 
validated  MNSs  and  ORDs  that  fall  under  the  CRD.  The  JCPAT  database 
and  the  initial  CRD  working  group  meetings  should  identify  these 
documents.  If  the  CRD  lead  identifies  AC  AT  II  and  below  programs 
under  the  CRD  he  can  forward  a  recommendation  to  the  JROC  that  a 
program  be  designated  JROC  special  interest  if  appropriate.  The  CRD 
lead  will  accompany  all  MNS/ORDs,  under  the  CRD,  through  the  JROC 
and  acquisition  milestone  reviews  to  ensure  the  CRD  mission  area 
capabilities  and  the  ORD  system  functional  and  interoperability 
requirements  are  properly  addressed. 

(3)  DOD  components.  DOD  components  may  develop  CRDs  to 
manage  a  component  unique  FoS/SoS  mission  area.  Prior  to  the  CRD 
definition  phase  the  DOD  component  will  forward  a  memorandum  to  the 
JROC  secretariat  stating  the  title,  mission  area,  and  timeline  of  the 
proposed  CRD  (this  will  minimized  the  duplication  and  undesirable 
overlap  if  current  CRDs  exist  for  the  mission  area).  All  draft  CRDs 
developed  by  DOD  components  will  be  submitted  to  J8  for  review  and 
determination  for  JROC  special  interest  prior  to  validation  and  approval. 
J8  will  use  the  AIS  process  described  in  enclosure  B  for  this 
determination.  For  those  CRDs  not  designated  JROC  special  interest, 
DOD  components  will  be  granted  validation  and  approval  authority. 

b.  CRD  Definition  Phase.  A  CRD  must  identify  operational  concepts, 
overarching  capabilities,  requirements  for  the  mission  area  FoS/SoS,  and 
the  scope  of  the  individual  systems  envisioned  to  compose  the  FoS/SoS. 
The  CRD  must  identify  criteria  against  which  various  combinations  of 
systems  and  the  contributions  of  individual  systems  can  be  evaluated. 

(1)  CRD  Development.  CRDs  expand  upon  the  capabilities  and 
deficiencies  identified  in  a  MNS,  or  ties  together  requirements  identified 
in  multiple  MNSs/ORDs.  The  analysis  used  in  developing  the  CRD 
should  take  into  account  appropriate  results  and  insights  from  previous 
assessments,  operational  experience,  lessons  learned  from  actual 
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deployments,  exercises,  test  and  evaluation,  experimentation,  technology 
demonstrations  and  other  sources  that  can  identify  the  capabilities 
required  for  the  FoS/SoS.  The  CRD  should  also  identify  the  factors  that 
drive  the  timing  of  the  requirements  such  as  retirement  of  existing 
systems  or  expected  timing  of  a  new  threat. 

c.  CRD  Documentation  Phase.  The  CRD  format  is  found  in  appendix 
A  of  this  enclosure.  The  CRD  lead  in  coordination  with  the  appropriate 
Services,  CINCs,  and  DOD  agencies  will  develop  the  proposed  FoS/SoS 
capabilities.  The  CRD  will  include  a  description  of  the  operational 
capability,  threat,  shortcomings  of  existing  systems,  and  capabilities 
required  for  the  family  of  systems. 

(1)  Operational  capability 

(a)  Defines  the  principal  mission  areas  and  functions  that  apply 
to  the  CRD  (e.g.,  Missions  under  the  TMD  CRD  include  Ballistic  Missile 
Defense,  Ground-Based  Anti -Air  and  Tactical  Missile  Defense). 

(b)  Defines  secondary  missions  for  those  systems  that  have 
capabilities  that  support  the  CRD  mission  area. 

(c)  Defines  the  CRD  FoS/SoS  and  the  concept  that  requires  how 
component  systems  are  designed  to  interoperate  with  other  component 
systems  as  a  condition  of  membership  in  the  family  (e.g.  the  family  of 
UAV  systems  including  the  High  Altitude  endurance,  Medium  Altitude 
endurance  and  tactical  UAVs). 

(d)  Defines  the  operational  elements  for  the  CRD  mission  area 
(e.g.  TMD  CRD  operational  elements  included  TMD  C41,  attack 
operations,  active  defense,  etc.). 

(e)  Defines  the  operational  concepts  for  the  CRD  mission  area. 
This  includes  the  C4ISR  (information  exchange)  operational  concept 
which  will  support  the  development  of  the  operational  architecture  for 
the  mission  area. 

(f)  Defines  the  operational  suitability  and  infrastructure  support 
of  the  CRD  mission  area.  Operational  suitability  is  the  degree  to  which  a 
system  supporting  the  mission  area  can  be  satisfactorily  fielded, 
deployed,  operated  and  sustained  while  meeting  collective  FoS 
performance  parameters  and  the  user's  needs  for  system  effectiveness. 

(2)  Threat.  Defines  the  principal  threat  for  the  CRD  mission  area 
(e.g.,  nature  of  threat,  threat  tactics,  future  threat  capabilities). 
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(3)  Shortcomings  of  existing  systems.  Defines  shortcomings  of 
fielded  or  planned  capabilities  to  counter  all  anticipated  threats  (e.g., 
weapon  system,  interoperability,  planning).  Describes  why  existing 
C4ISR  architectures  (operational,  systems  and  technical  views)  cannot 
meet  current  or  projected  future  (joint)  requirements  for  the  proposed 
FoS/SoS. 

(4)  Capabilities  Required.  The  CRD  should  identify  the  operational 
requirements  which  articulate  the  capabilities  JFCs  require  to  conduct 
operations  within  the  CRD  mission  area.  An  operational  requirement  is 
a  system  capability  or  characteristic  required  to  accomplish  approved 
mission  needs.  The  requirements  shall  have  appropriate  criteria  and 
rationale  for  each,  and  be  stated  in  threshold /objective  if  appropriate.  A 
single  overarching  requirement  transcends  all  others,  all  CRD  systems 
must  be  interoperable.  Timing  of  requirements  should  specify  the  time- 
based  nature  of  the  need  and  the  events  that  are  driving  that  need. 
Requirements  other  than  interoperability  that  must  be  flowed  down 
exactly  or  with  some  specific  limits  will  be  included  and  clearly  stated  in 
the  CRD.  One  method  to  identify  requirements  is  to  list  all  the  required 
capabilities  for  each  operational  elements  for  the  CRD  (see  Figure  8). 


Operational  Element 

Requirements 

C4I 

Combat  ID  capability 
Common  Tactical  Picture 
Signature  Data 

Etc. 

Attack  Operations 

BDA 

Weapon/Target  Pairing 
Etc. 

General 

Transportation 

Modeling  and  Simulation 
Etc. 

Etc. 

Figure  8.  Example  CRD  requirements  roll-up 

(a)  Information  Exchange  Requirements  (IERs).  The  warfighter 
also  needs  to  identify  the  top  level  essential  interface  requirements  for 
information  exchange  needed  to  support  the  CRD  FoS/SoS  as  described 
in  (reference  p) .  IERs  identify  the  elements  of  warfighter  information 
used  in  support  of  a  particular  activity  and  between  any  two  activities. 
IERs  are  to  be  used  as  the  primary  basis  and  measure  for  FoS/SoS 
interoperability  in  defining  Interoperability  KPP  threshold  (T)  and 
objective  (O)  requirements  for  ORDs  and  CRDs.  The  requirements  should 
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reflect  both  the  information  needs  necessary  to  satisfy  the  system(s) 
under  consideration  and  the  information  this  new  capability  can  provide 
to  enhance  fielded  systems. 

(b)  Interoperability.  Joint  Pub  1-02  definition  1  for 
Interoperability  defines  it  as  the  ability  of  systems,  units,  or  forces  to 
provide  services  to  and  accept  services  from  other  systems,  units,  or 
forces  and  to  use  the  services  so  exchanged  to  enable  them  to  operate 
effectively  together.  Even  though  there  are  many  facets  of 
interoperability  (e.g.,  fuel,  ammunition,  transportation,  communications) 
that  need  to  be  identified  in  the  CRD  the  focus  for  the  interoperability 
CRD  KPP  will  be  the  information  exchange  and  level  of  interoperability 
for  the  CRDs  systems  information  needs.  The  CRD  IERs  and 
Interoperability  KPP  will  be  the  CRD  leads  guidance  for  future  ORD 
C4ISR  development  and  issues  to  be  addressed  in  legacy  systems.  The 
IERs  are  one  product  that  is  required  to  support  development  of  the 
C4ISR  operational  architecture  for  the  CRD  mission  area  and  the 
continued  evolution  of  the  Joint  C4ISR  Operational  Architecture  (JOA). 
The  development  of  the  information  exchange  requirements  should  cover 
both  the  communication  requirements  for  command  and  control  of  the 
CRD  systems  and  the  level  of  integration  for  cross  system  operations  as 
depicted  in  Figure  9.  Information  Assurance  (LA)  is  required  for  all  DOD 
systems  that  are  used  to  enter,  process,  store,  display,  or  transmit  DOD 
information  regardless  of  classification  or  sensitivity.  To  assure  balance 
or  risk  and  gains,  LA.  requirements  must  be  co-developed  and  co-evolved 
with  those  for  Information  Interoperability. 


Figure  9.  CRD  Interoperability 
(c)  CRD  Key  Performance  Parameters  (KPP) .  A  CRD  KPP  is  a 
capability  or  characteristic  so  significant  it  is  essential  for  defining  the 
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FoS/SoS  required  capabilities.  CRD  KPPs  should  be  limited  in  number, 
output  oriented,  stated  in  Threshold /Objective  format,  and  measurable 
to  facilitate  analysis  of  the  progress  in  reaching  the  capabilities  outlined 
in  the  CRD.  The  ORDs  under  the  CRD  must  address  the  CRD  KPPs 
relevant  to  the  particular  operational  element  they  support.  ORDs  are 
not  expected  to  address  a  CRD  KPP  if  it  does  not  apply  to  the  proposed 
system. 


(1)  CRD  KPP  Development.  Selection  of  valid  KPPs  is  more 
than  just  identifying  a  requirement  and  providing  a  threshold /objective 
value.  A  KPP  should  be  a  roll-up  of  a  number  of  supporting 
requirements  listed  in  the  CRD.  All  CRDs  will  have  as  a  minimum  an 
Interoperability  KPP.  The  following  is  one  methodology  used  to  develop 
CRD  KPPs: 

Step  (1).  List  the  requirements  for  each  Operational  Element 
identified  under  operational  capabilities  for  the  CRD  as  described  above. 

Step  (2).  Prioritize  the  supporting  requirements  for  each  element. 

Step  (3).  For  each  operational  element  build  one  measurable 
performance  parameter  that  captures  the  essence  of  the  requirements  in 
the  group. 

Step  (4).  Do  the  same  for  each  identified  element. 

Step  (5).  Determine  the  parameters  that  are  most  critical  to  the 
CRD  mission  area  and  designate  them  as  Key  Performance  Parameters 
for  the  CRD. 

Note:  All  of  the  operational  elements  identified  do  not  necessarily  need  to 
create  a  CRD  KPP.  Likewise,  an  operational  element  could  create  two  or 
more  CRD  KPPs  if  appropriate. 

(2)  CRD  Interoperability  KPP.  The  CRD  Interoperability  KPP 
should  define  the  level  of  interoperability  for  cross  family  systems 
operation,  (e.g.  TMD  CRD  C4I  Interoperability  KPP  Criteria:  The  TMD  FoS 
must  have  the  ability  to  conduct  collaborative  planning,  battle 
management,  weapons  coordination  and  engagement  to  support  TMD 
operations  at  the  joint  operational  and  tactical  levels.  The  TMD  FoS 
must:  possess  a  common  interface  among  individual  systems  (T);  migrate 
to  full  JTA  compliance  (O)  (as  applicable  to  individual  systems)) .  The 
CRD  Interoperability  KPP  will  use  IERs  as  the  primary  measure  for 
interoperability  and  will  outline  the  specific  framework  for  CRD  ORDs  to 
follow. 
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d.  CRD  Validation  Phase.  The  validation  phase  is  the  formal  review 
process  of  the  CRD  by  an  operational  authority  other  than  the  user. 

(1)  JROC  validation.  The  JROC  has  validation  authority  for  all 
CRDs  unless  a  DOD  component  has  been  granted  validation  and 
approval  authority.  Any  CRD  forwarded  for  JROC  validation  is 
considered  to  be  a  draft.  The  CRD  lead  will  forward  the  draft  document 
and  a  summary  of  the  analysis  used  to  support  the  CRD  development. 
The  first  step  in  obtaining  validation  is  the  JROC  formal  review  of  the 
document.  The  formal  review  process  is  described  in  enclosure  B. 

(2)  DOD  component  validation.  The  Chief/ Director  of  a  DOD 
component  will  validate  component  unique  CRDs  for  which  they  have 
been  granted  validation  and  approval  authority  by  the  JROC. 

e.  CRD  Approval  Phase 

(1)  JROC  approval.  The  approval  authority  for  all  CRDs  is  the 
JROC  unless  a  DOD  component  has  been  granted  validation  and 
approval  authority  .  Following  CRD  approval,  the  JROC  Chairman  will 
forward  a  JROCM  to  USD  (A&T)  and  ASD  (C3I)  for  information.  The  CRD 
lead  will  provide  a  signed  copy  of  the  CRD  to  the  JROC  secretariat  for 
historical  tracking. 

(2)  DOD  component  approval.  The  Chief/ Director  of  a  DOD 
component  is  the  approval  authority  for  component  unique  CRDs  for 
which  they  have  been  granted  validation  and  approval  authority  by  the 
JROC.  Following  CRD  approval,  the  DOD  component  will  forward  a 
signed  copy  of  the  CRD  to  the  JROC  secretariat  for  historical  tracking. 

f.  CRD  Review  and  Revalidation.  The  CRD  lead  should  review  the 
document  annually  and  update  as  necessary  or  when  directed  by  the 
JROC.  Significant  changes  in  required  capability,  threat  or  doctrine  are 
reasons  for  CRD  update.  Updated  CRDs  will  be  submitted  to  the 
approval  authority  for  validation  and  approval. 
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APPENDIX  A  TO  ENCLOSURE  D 

CAPSTONE  REQUIREMENTS  DOCUMENT  FORMAT 

CAPSTONE  REQUIREMENTS  DOCUMENT 
FOR 
TITLE 

Date 


1.  General  Description  of  Operational  Capability. 

-  Introduction 

-  Describe  CRD  analysis  and  development  process  and  DOD 
components  that  participated 

-  Mission  Area  Description 

-  Summarize  the  mission  need 

-  Identify  all  related  documents  that  impact  CRD  (MNS  or 
other  CRDs)  or  are  impacted  by  the  CRD  (other  CRDs  or  ORDs  already  in 
existence.  State  if  any  other  CRDs  will  be  superseded  or  made  obsolete 
by  this  CRD 

-  Identify  the  possible  implications  for  change  to  joint  doctrine 

-  CRD  Family- of- Systems 

-  Describe  the  FoS/SoS  concept 

-  CRD  operational  elements 

-  Identify  the  operational  elements  that  are  required  to 
support  the  CRD  mission  area 

-  Operational  Concept 

-  Define  the  CRD  mission  operational  concept 

-  Define  the  C4ISR  operational  concept 

-  Operational  Suitability  and  Infrastructure  Support 

-  Define  General  and  Specific  guidance  for  suitability  and 
infrastructure  support 

-  Define  other  Support  considerations 

2.  Threat.  Summarize  the  nature  of  the  threat  to  be  countered,  threat 
tactics,  and  projected  future  threat  environment  for  the  mission  area. 
This  threat  information  should  reference  Defense  Intelligence  Agency 
(DIA)  validated  documents. 
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3.  Shortcomings  in  Mission  Area  and  Existing  systems 


-  Describe  the  shortcomings  or  absence  of  existing  capabilities 
and  systems  to  fulfill  the  needs  of  the  mission  area  in  the  context  of  the 
postulated  threat  (e.g.,  weapon  systems,  interoperability,  planning). 

-  Describe  why  existing  C4ISR  operational,  systems  and  technical 
architectures  views  cannot  meet  current  or  projected  future  (joint) 
requirements  for  the  proposed  FoS/SoS. 

Note:  The  intent  is  not  to  build  a  CRD  unique  C4ISR  architecture.  In 
detail  describe  the  proposed  missing  piece  of  currently  established 
architectures  that  needs  to  be  addressed  to  accomplish  the  mission. 

4.  Capabilities  Required.  Describe  the  requirements  for  the  CRD 
operational  elements  (see  figure  10).  Provide  criteria  and  rationale  for 
each  requirement  and  identify  the  threshold /objective  if  appropriate. 


Operational  Element 

Requirements 

C4I  (common  to  all  pillars) 

Combat  ID  Capability 

Surveillance,  Detection  and  tracking 
Common  Operational  Picture 

Spectrum  supportability 

Bandwith  Management/ Capacity 

Etc. 

Attack  Operations 

Attack  Operations  Effectiveness 

Attack  Operations  C4I 

Attack  Operations  RSTA 

Battle  Damage  Assessment 

Etc. 

Active  Defense 

Active  Defense  C4I 

Engagement  Assessment 

Autonomous  Operations 

Etc. 

Passive  Defense 

Impact  Point  Prediction 

Inducing  Targeting  Error 

Recovery  and  Reconstitution 

Etc. 

General 

Transportation 

Modeling  and  Simulation 

Minimum  Operational  Capabilities 
Information  Warfare 

Electromagnetic  Environmental  effects  (E3) 
Etc. 

Figure  10.  Example  Requirement  Summary 

-  Timing  of  requirements  should  specify  the  time-based  nature  of 
the  need  and  the  events  that  are  driving  that  need. 
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-  Develop  the  CRD  KPPs  as  outlined  in  Enclosure  D.  Figure  1 1 
provides  example  KPP  table  summary.  Develop  the  CRD  IERs  matrix,  in 
accordance  with  procedures  described  in  the  C4ISR  Architecture 
Framework  and  from  the  IER  matrix  develop  the  Interoperability  CRD 
KPP  as  outlined  in  Enclosure  D. 


Key  Performance  Parameter 

Threshold  and  Objective 

Interoperability 

As  appropriate 

Combat  ID 

" 

Early  Warning 

" 

Etc. 

" 

Figure  1 1 .  Example  KPP  table  summary 


Appendixes: 

A:  References 

B:  Distribution  List 

C:  List  of  CRD  supporting  analysis 

Glossary: 


Part  I:  Abbreviations  and  Acronyms 
Part  II:  Terms  and  Definitions 

Tables: 

A:  Operational  Element  and  supporting  requirements  summary 
B:  CRD  KPP  summary 

C:  CRD  IER  Matrix  (extracted  from  Figure  OV-3  from  reference  p) 
D:  As  required. 
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ENCLOSURE  E 

OPERATIONAL  REQUIREMENTS  DOCUMENT  GENERATION  PROCESS 
1.  Operational  Requirements  Document  (ORD) 


a.  General.  The  ORD  is  a  formatted  document  containing  operational 
performance  requirements  for  a  proposed  concept  or  system.  The  system 
proposed  for  continued  evaluation  in  later  acquisition  phases  shall  be 
described  in  an  initial  ORD  in  terms  that  define  the  system  capabilities 
needed  to  satisfy  the  mission  need.  The  requirements,  stated  as 
operational  performance  parameters  in  the  initial  ORD,  shall  be  tailored 
to  the  system  (e.g.,  satellite,  aircraft,  ship,  missile,  or  weapon)  and  reflect 
system-level  performance  capabilities  such  as  range,  probability  of  kill, 
platform  survivability,  and  the  timing  of  the  need,  etc.  The  four  phases 
of  the  ORD  generation  process  are  depicted  in  Figure  12. 


ADM 

MNS  &  CRD 

MAA/MNA 

OTHER  ANALYSIS 

JOINT  INTEREST 

THREAT 

STRATEGY 

DOCTRINE 

POLICY 

TECHNOLOGY 

EXISTING  CAPABILITIES 

EXPERIMENT  RESUL  TS 

ACTD  RESULTS 

EXERCISE  RESULTS 

TEST &EVAL  RESULTS 


DEFINITION 

LEAD  DOD 
COMPONENT 


DOCUMENTATION 

LEAD  DOD 
COMPONENT 


VALIDATION 


APPROVAL 


AC  AT  I  D/I  A 


JROC 


Figure  12.  ORD  Generation  Process 


b.  ORD  Definition  Phase.  The  definition  phase  defines  and  justifies 
the  development  of  a  ORD.  The  ORD  sponsor  will  apply  Analysis-of- 
Alternatives  (AO A),  risk  reduction  demonstrations,  military  utility 
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assessments,  Advance  Concept  Technology  Demonstrations  (ACTD), 
Advanced  Technology  Demonstrations  (ATD),  experimentation,  test  and 
evaluation,  cost-schedule-performance  tradeoff,  requirements  cost 
tradeoffs,  and  affordability  analysis  in  the  development  of  draft  ORD 
requirements  (especially  KPPs).  These  parameters  best  characterize  the 
most  promising  concept(s)  to  be  pursued  in  a  new  acquisition  program. 
Also,  as  DOD  moves  to  reduce  cycle  time  of  traditional  acquisition 
activities,  through  evolutionary  acquisition,  the  ORD  will  serve  as  the 
vehicle  for  documenting  successive  operational  requirements  and 
managing  the  scope  of  that  acquisition  process.  The  ORD  should  also 
identify  the  factors  that  drive  the  timing  of  the  requirements  such  as 
retirement  of  existing  systems  or  expected  timing  of  a  new  threat. 

(1)  Time  Phased  Requirements  in  support  of  Evolutionary 
Acquisition.  Evolutionary  acquisition  is  a  streamlined  acquisition 
strategy  that  fields  a  core  capability,  with  a  modular  open  structure  and 
provides  for  additional  future  increments  in  capability  upgrades.  Time 
phased  requirements  support  evolutionary  acquisition  in  phases  by 
allowing  systems  to  be  delivered  to  the  field  in  increasing  increments  of 
capability.  The  future  (follow  on)  increments  are  developed  as  blocks  or 
models  by  the  acquisition  community  as  requirements  are  refined  by  the 
warfighter's  increased  understanding  of  the  delivered  capability,  the 
evolving  threat,  and  available  technology.  The  proposed  approach  for 
subsequent  incremental  developments  should  be  included  in  the 
acquisition  strategy  documents.  Depending  on  the  size  and  scope  of  the 
additional  capability,  some  increments  may  need  be  covered  by  an 
annex  to  the  existing  ORD,  may  require  a  new  ORD,  or  a  manner  agreed 
to  by  the  JROC.  Evolutionary  acquisition  plans  should  be  consistent 
with  other  acquisition  plans  and  developed  by  the  acquisition 
community  with  the  support  of  the  user  community.  Evolutionary 
acquisition  is  a  preferred  approach  but  is  not  necessarily  appropriate  for 
all  development  efforts.  Automated  Information  Systems  are  prime 
candidates  for  evolutionary  acquisition. 

(2)  Demonstrations  to  assess  military  utility.  Military  utility 
demonstrations  such  as  ACTDs,  ATDs,  requirements  definition/technical 
demonstration  activities  during  PDRR  or  experimentation  should  be 
considered  for  concurrent  requirements  generation  and  concept  risk 
reduction.  Military  utility  demonstrations  should  be  conducted  by  the 
CINCs  and  Services  to  ensure  user /warfighter  involvement  early  in  the 
requirements  generation  process.  During  PDRR  the  program  may 
employ  one  or  more  design  concepts  to  demonstrate  technical  maturity, 
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facilitate  analysis  of  alternatives,  support  CAIV  trades  and  refine 
threshold  and  objectives  initially  stated  as  broad  measures  of 
effectiveness. 

(3)  Advanced  Concept  Technology  Demonstrations.  The  goal  of 
ACTDs  is  to  assess  the  military  utility  of  a  significant  new  capability  and 
to  conduct  that  assessment  at  a  scale  size  adequate  to  clearly  establish 
operational  utility  and  system  integrity.  The  JROC  will  prioritize 
proposed  ACTD  candidates,  together  with  proposed  CINC  sponsor  and 
Lead  Service/Agency.  Once  the  ACTDs  are  prioritized  the  JROC  will 
forward  the  prioritization  with  CINC  sponsor  and  lead  service  or  agency, 
via  JROCM,  to  USD  (A&T).  This  action  equates  to  a  mission  need 
determination  for  each  ACTD.  The  lead  service  is  responsible  to  develop 
the  Operational  Requirements  Document  for  ACTDs  that  have  shown 
military  utility  and  have  been  approved  to  transition  to  the  formal 
acquisition  process.  The  ACTD  management  plan  should  address  the 
schedule  for  anticipated  ORD  development  to  ensure  a  smooth  transition 
to  the  acquisition  process.  The  JROC  requests  that  if  funding  is 
insufficient  to  support  the  candidates  in  priority  order,  the  JROC  be 
consulted  regarding  the  rationale  for  implementing  the  ACTDs  out-of- 
priority  order. 

(4)  CRD  interface.  DOD  components  will  determine  if  the  ORD  they 
are  developing  falls  under  any  existing  CRD.  If  the  ORD  is  under  a  CRD 
mission  area  then  the  ORD  sponsor  must  work  closely  with  the  CRD  lead 
during  ORD  definition  and  development.  The  JCPAT  database  and  the 
Joint  Staff  J-8  will  catalog  all  validated  and  approved  CRDs. 

c.  ORD  Documentation  Phase.  The  ORD  format  can  be  found  in 
Appendix  A  of  this  enclosure.  The  ORD  sponsor  in  coordination  with  the 
appropriate  DOD  components  will  prepare  the  ORD.  The  ORD  provides  a 
bridge  that  links  the  needs  and  capabilities  identified  in  the  MNS  and 
CRD  (if  applicable)  to  the  Acquisition  Program  Baseline  (APB)  and  the 
contractual  specifications  for  a  program.  The  ORD  should  be  written  at 
the  appropriate  level  to  describe  the  system  and  is  initially  submitted  at 
Milestone  I  with  broad  objectives  and  acceptable  requirements.  The 
initial  ORD  will  include  the  evaluation  of  requirements  based  on 
commercial  market  potential  required  by  reference  b.  As  a  program  is 
further  defined  between  the  acquisition  milestones,  the  ORD  is  updated 
to  reflect  the  results  of  analysis,  experimentation,  testing,  technology 
insertion,  CAIV  and  cost-schedule-performance  trades.  If  the  program 
falls  under  a  CRD,  the  ORD  will  show  linkage  and  the  contribution  to  the 
appropriate  CRD  operational  requirements  and  CRD  KPPs.  The  ORD  will 
include  a  description  of  operational  capability,  threat,  shortcomings  of 
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existing  systems  and  C4ISR  architectures,  capabilities  required  for  the 
system,  program  support,  force  structure  and  schedule/program 
affordability  for  the  system. 

(1)  Description  of  Operational  Capability 

(a)  Summarizes  the  mission  need. 

(b)  Describes  the  overall  mission  area(s)  that  the  system  will 
support.  Identify  the  CRD(s)  that  impact  the  system  (if  appropriate). 

(c)  Describes  the  type  of  system  proposed. 

(d)  Define  the  missions  that  the  system  will  perform  (e.g.,  CAS, 
SEAD,  Interdiction). 

(e)  Defines  the  operational  and  support  concept(s)  for  the 
proposed  system.  This  includes  the  C4ISR  (information  exchange) 
operational  concept. 

(f)  Describes  if  fielding  of  increments  (time  phased)  of  system 
capability  that  support  evolutionary  acquisition  is  appropriate  for  the 
proposed  system. 

(2)  Threat.  Defines  the  principal  threat  for  the  system  (e.g.,  nature 
of  threat,  threat  tactics,  future  threat  capabilities). 

(3)  Shortcomings  of  existing  systems  and  C4ISR  architectures. 
Defines  shortcomings  of  fielded  systems  to  counter  all  anticipated 
threats  (e.g.,  weapon  system,  interoperability,  lift).  Describes  why 
existing  C4ISR  architectures  (operational,  systems  and  technical  views) 
cannot  meet  current  or  projected  future  (joint)  information  exchange 
requirements  for  the  proposed  system. 

(4)  Capabilities  Required.  The  initial  ORD  will  establish 
requirements  describing  the  capabilities  and  characteristics  of  the 
proposed  system.  The  requirements  shall  be  written  in  output  oriented 
and  measurable  terms  in  Threshold  /Objective  format  with  criteria  and 
rationale  for  each.  The  ORD  shall  identify  the  specific  requirements 
contributing  most  significantly  to  the  desired  operational  capability  and 
provide  a  relative  importance  of  meeting  or  exceeding  each  requirement 
threshold  or  objective  value.  This  will  be  used  to  guide  the  acquisition 
community  in  making  trade  off  decisions  between  the  threshold  and 
objective  levels  of  the  stated  requirements.  The  ORD  requirements 
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(especially  KPPs)  and  supporting  rationale  should  reflect  analytic 
insights  on  the  preferred  alternative(s)  identified  in  the  Analysis-of- 
Alternatives  (AOA),  cost-schedule-performance  tradeoffs,  requirements 
cost  tradeoffs,  experimentation,  test  and  evaluation,  and  affordability 
analysis.  The  ORD  requirements  shall  be  refined  at  successive 
milestone  decision  points  based  upon  the  trade-offs  made  during  each 
phase  of  the  acquisition  process.  One  method  to  identify  requirements 
is  to  list  all  the  required  capabilities  for  each  mission  area/function  for 
the  proposed  system  (see  Figure  13). 


Mission  /  F  unction 

Capabilities  required 

CAS 

Combat  radius 
Targeting 

Payload 

Etc. 

Defensive  Counter 
Air 

Maneuverability 

Acceleration 

Combat  radius 

Etc. 

C41SR 

Combat  ID 

Battlespace  Awareness 
Off  board  sensor  inputs 
Etc. 

Etc. 

Etc. 

Figure  13.  Example  ORD  Capabilities  required 

(a)  Information  Exchange  Requirements  (lERs).  The  warfighter 
also  needs  to  identify  the  top  level  essential  interface  requirements  for 
information  exchange  needed  to  support  the  proposed  system  as 
described  in  reference  r.  lERs  identify  the  elements  of  warfighter 
information  used  in  support  of  a  particular  activity  and  between  any  two 
activities.  lERs  are  to  be  used  as  the  primary  basis  and  measure  for 
system  interoperability  in  defining  Interoperability  KPP  threshold  (T)  and 
objective  (O)  requirements  for  ORDs  and  CRDs.  These  lERs  should  be 
limited  to  only  the  top  level  requirements  that  identify  the  on-board  and 
off-board  informational  needs  for  the  system  to  support  the 
interoperability  requirement.  The  lERs  will  be  extracted  from  the  ORD 
along  with  the  Interoperability  KPP  and  utilized  in  the  C41SP  as  one  of 
the  tools  used  to  develop  the  operational  architecture  for  the  system. 

The  goal  is  to  use  established  architectures  for  information  exchange  and 
identify  unique  system  information  requirements  that  can  not  be 
supported  with  current/projected  architectures.  The  intent  is  to 
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eliminate  duplication  and  having  individual  systems  creating  their  own 
(stovepiped)  C4ISR  architectures. 

(b)  Interoperability.  Joint  Pub  1-02  definition  (2)  for 
interoperability  defines  it  as  the  condition  achieved  among 
communications-electronics  systems  or  items  of  communications - 
electronics  equipment  when  information  or  services  can  be  exchanged 
directly  and  satisfactorily  between  them  and/or  their  users.  Even 
though  there  are  many  facets  of  interoperability  (e.g.,  fuel,  ammunition, 
transportation,  communications)  that  need  to  be  identified  in  the  ORD 
the  focus  for  the  interoperability  ORD  KPP  will  be  the  information 
exchange  and  interoperability  level  for  the  ORD  system  information 
needs.  The  intent  is  for  the  warfighter  to  outline  the  essential 
information  exchange  requirements  for  the  system  as  described  above. 
The  requirements  should  reflect  both  the  information  needs  necessary  to 
satisfy  the  system  under  consideration  and  the  information  this  new 
capability  can  provide  to  enhance  fielded  systems.  The  development  of 
the  information  exchange  requirements  should  cover  both  the 
communication  requirements  for  command  and  control  of  the  proposed 
system  and  the  level  of  integration  for  cross  system  operations  as 
depicted  in  Figure  14. 


A 


Communication 

Requirements 

For 

Command  &  Control 


\ 


\ _ / 


Weapon  System 
Needs 

Traditional  Weapon 
System  Focus 


/ 

\ 


Level  of  Integration 
For 

Cross-system 

Operations 


Information 

Needs 

Network  Requirements 
System  Requirements 


Figure  14.  ORD  Interoperability 
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Information  Assurance  (IA)  is  required  for  all  DOD  systems  that  are  used 
to  enter,  process,  store,  display,  or  transmit  DOD  information  regardless 
of  classification  or  sensitivity.  IA  is  defined  as  the  Information 
Operations  that  protect  and  defend  information  and  information  systems 
by  ensuring  their  availability,  integrity,  authentication,  confidentiality, 
and  non-repudiation  and  included  restoration  through  protection, 
detection,  and  reaction  capabilities.  To  assure  balance  or  risk  and  gains, 
IA  requirements  must  be  co-developed  and  co-evolved  with  those  for 
Information  Interoperability  (reference  i). 

(c)  ORD  Key  Performance  Parameters  (KPPs).  ORD  KPPs  are 
those  system  capabilities  or  characteristics  considered  essential  for 
successful  mission  accomplishment.  The  ORD  should  only  contain  a 
limited  number  of  KPPs  (approximately  8  or  fewer)  that  capture  the 
parameters  needed  to  reach  the  overall  desired  capabilities  for  the 
system.  Failure  to  meet  an  ORD  KPP  threshold  can  be  cause  for  the 
system  selection  to  be  reevaluated  or  the  program  to  be  reassessed  or 
terminated.  ORD  KPPs  are  extracted  from  the  ORD  and  included  in  the 
performance  section  of  the  Acquisition  Program  Baseline  (APB)  document 
at  each  Milestone  beginning  with  Milestone  I.  ORDs  will  have  an 
Interoperability  KPP.  The  following  guidelines  should  be  applied  when 
selecting  KPPs: 

-Is  it  essential  for  defining  system  or  required  capabilities? 

-Is  it  warfighting  oriented  or  does  it  contribute  to  the  improvement 
in  warfighting  capabilities? 

-Is  it  achievable  / testable? 

-Can  the  numbers/percentages  be  explained  by  analysis? 

-If  not  met,  are  you  willing  to  look  at  canceling  the  program? 

(d)  ORD  KPP  Development.  Selection  of  valid  KPPs  is  more 
than  just  identifying  a  requirement  and  providing  a  threshold /objective 
value.  A  KPP  should  be  a  roll-up  of  a  number  of  supporting 
requirements  developed  listed  in  the  ORD.  The  following  is  one 
methodology  for  developing  KPPs: 

Step  (1)  List  system  required  capabilities  for  each 
mission/function  as  described  above. 

Step  (2)  Prioritize  these  requirements. 

Step  (3)  For  each  mission/function  build  one  measurable 
performance  parameter. 
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Step  (4)  Determine  the  parameters  that  are  most  critical  to  the 
system  and  designate  them  as  Key  Performance  Parameters  in  the  ORD. 

Note:  All  missions/functions  for  the  system  to  not  need  to  create  a  KPP. 
Likewise,  certain  areas  may  create  two  or  more  KPPs. 

(e)  ORD  Interoperability  KPP.  The  ORD  Interoperability  KPP 
should  define  the  level  of  interoperability  for  the  proposed  system,  (e.g. 
PAC-3  ORD  Interoperability  KPP  criteria:  TADIL-J  (T),  Joint  Composite 
Tracking  Network  (JCTN)  (O)).  The  Interoperability  KPP  will  be  derived 
from  the  set  of  IERs  that  characterize  the  information  exchanges  to  be 
performed  by  the  proposed  system.  ORDs  that  come  under  the  umbrella 
of  a  CRD  should  ensure  compliance  with  the  CRD  Interoperability  KPP. 

(f)  ORD  sponsor/CRD  lead  interface.  If  the  ORD  falls  under  a 
CRD  the  ORD  sponsor  will  work  closely  with  the  CRD  lead  to  ensure 
ORD/CRD  C4ISR  interoperability. 

(2)  Program  Affordability.  Cost  will  be  addressed  in  the  ORD. 
Inclusion  of  cost  allows  the  DOD  component  sponsor  to  emphasize 
affordability  early  in  the  proposed  program.  The  cost  figure  should  be 
stated  in  terms  of  a  threshold  and  objective  (not  necessarily  a  KPP)  in 
order  to  provide  flexibility  to  allow  for  program  evolution  and  CAIV  trade 
studies.  The  DOD  component  sponsor  may  make  cost  a  KPP  if  it  desires 
and  identify  the  cost  it  wishes  to  evaluate.  The  cost  will  be  extracted 
from  the  ORD  and  included  in  the  cost  section  of  the  APB. 

d.  ORD  Validation  Phase.  The  validation  phase  for  an  ORD  includes 
the  formal  review  of  the  document  to  confirm  the  operational 
requirements  for  the  system.  The  validation  authority  for  the  ORD  is 
dependent  upon  potential  ACAT  level  and/or  if  a  program  is  designated 
JROC  special  interest. 

(1)  JROC  Validation. 

(a)  Milestone  I.  All  ACAT  I/LA  and  designated  JROC  special 
interest  ORDs  will  be  reviewed  and  their  KPPs  validated  by  the  JROC  at 
Milestone  I. 

(b)  Milestone  II/III.  The  JROC  will  review  ACAT  ID/IAM  and 
JROC  special  interest  ORDs  at  Milestone  II  and  III  to  support  each 
milestone  decision.  The  JROC  maintains  validation  authority  for  ACAT 
ID/IAM  ORDs  even  if  the  JROC  has  delegated  ORD  approval  authority  to 
a  DOD  component.  The  JROC  will  also  review  the  ACAT  ID/IAM  ORDs  if 
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a  recommendation  is  made  to  change  a  KPP  at  any  time  during  the  life  of 
a  program.  The  JROC  retains  authority  to  review  AC  AT  IC/IAC  ORDs  if 
there  are  changes  to  JROC  validated  KPPs,  otherwise  ACAT  IC/IAC  ORDs 
need  not  return  to  the  JROC  for  Milestone  II  and  III  decisions. 

(2)  POD  Component  Validation.  The  Chief/Head  of  a  DOD 
component  head  (or  as  delegated)  may  validate  their  own  ACAT  IC/IAC 
and  below  ORDs  at  Milestone  II  and  III,  if  ORD  approval  has  been 
delegated  to  the  DOD  component  and  JROC  validated  KPPs  are  not 
changed. 

(3)  Formal  ORD  Review.  The  first  step  in  obtaining  validation  is 
the  formal  review  of  the  document.  The  review  process  is  described  in 
Enclosure  B.  Any  ORD  forwarded  for  JROC  validation  is  considered  draft 
and  must  have  supporting  analysis  for  proposed  KPPs  along  with  the 
AOA,  if  appropriate,  included  in  the  package. 

e.  ORD  Approval  Phase.  The  ORD  approval  phase  documents  the 
approval  authority's  concurrence  with  the  final  validated  document. 
Approval  authority  is  dependent  upon  potential  ACAT  level,  if  designated 
JROC  special  interest,  or  if  approval  authority  has  been  delegated. 
Delegation  of  approval  authority  allows  the  designated  lead  DOD 
component,  with  coordination  with  the  appropriate  DOD  components,  to 
make  requirements  trades  between  acquisition  Milestones  without  JROC 
approval.  Key  Performance  Parameters  or  other  specifically  identified 
items  by  the  JROC  can  not  be  changed  without  JROC  approval. 

(1)  JROC  approval. 

(a)  Milestone  I.  The  approval  authority,  at  Milestone  I,  for  all 
potential  ACAT  I/LA  ORDs  and  KPPs  is  the  JROC.  The  JROC  will 
normally  delegate  ORD  approval  authority  for  potential  ACAT  I/LA.  ORDs 
to  the  DOD  component  sponsor  at  the  Milestone  I  JROC  review. 

However,  the  JROC  may  retain  approval  authority  for  selected  ACAT  I 
programs.  Following  JROC  approval,  the  JROC  Chairman  will  forward  a 
Milestone  review  and  lead  Service  recommendation,  including  a  list  of 
Key  Performance  Parameters,  to  USD(A&T)  via  JROCM  for  consideration 
during  the  DAB  or  to  ASD(C3I)  for  consideration  during  the  DOD  CIO 
review.  If  a  JROC  special  interest  program  is  not  going  to  a  DAB  or  DOD 
CIO  review,  the  recommendations  will  be  forwarded  to  the  appropriate 
DOD  component  milestone  decision  authority. 

(b)  Milestone  II/III.  The  JROC  will  approve  ACAT  ID /LAM  and 
JROC  special  interest  ORDs  at  Milestone  II  and  III  to  support  each 
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milestone  decision.  If  the  JROC  retained  approval  authority  for  an  AC  AT 
I/IA,  or  JROC  special  interest  program,  then  the  JROC  will  review  the 
ORD  and  KPPs  prior  to  each  milestone.  The  JROC  Chairman  will 
forward  a  Milestone  review  and  lead  Service  recommendation,  including  a 
list  of  Key  Performance  Parameters,  to  USD(A&T)  via  JROCM  for 
consideration  during  the  DAB  or  to  ASD(C3I)  for  consideration  during  the 
DOD  CIO  review. 

(2)  DOD  component  approval.  The  Chief/Head  of  the  DOD 
component  (or  as  delegated)  are  the  approval  authority  ACAT  IC/IAC,  II 
and  below  ORDs  if  ORD  approval  has  been  delegated  by  the  JROC  at 
Milestone  I.  Approved  ORDs  are  submitted  by  the  approval  authority  to 
the  appropriate  DOD  component  MDA  for  action. 

f.  ORD  Review/Revalidation.  The  ORD  is  refined  and  updated  when 
necessary  and  prior  to  each  acquisition  milestone  to  incorporate  results 
of  the  activities  during  each  acquisition  phase  (i.e.,  cost,  schedule,  and 
performance  trades,  testing,  and  analysis  of  alternatives  (AO A)).  There  is 
no  need  to  update  the  MNS  because  the  ORD  builds  upon  this  initial 
document.  The  ORD  should  be  thoroughly  reviewed  by  the  DOD 
component  sponsor,  including  other  appropriate  DOD  components  for 
joint  program  ORDs.  Any  changes  to  the  initial  ORD  will  be  carefully 
reviewed  by  the  ORD  validation  and  approval  authorities  to  determine 
whether  or  not  the  changes  in  the  requirements  should  apply  to  the 
system  currently  being  developed,  or  they  should  be  deferred  to 
subsequent  blocks  if  an  evolutionary  acquisition  approach  is  used.  Also, 
the  ORD  validation  and  approval  authorities  with  assistance  from  the 
development  and  test  communities  will  ensure  the  deficiencies  and 
requirements  are  still  valid  when  compared  to  the  latest  threat,  guidance, 
and  strategy  documents.  Also,  the  ORD  should  be  vigorously  scrubbed 
to  ensure  that  the  KPPs  reflect  the  minimum  essential  requirements. 

2.  Acquisition  Program  Baseline  (APB)  Procedures.  The  APB  contains 
the  cost,  schedule,  and  key  performance  parameters  for  the  program. 
APBs  are  described  in  reference  b,  section  3.2.2.  With  progression 
through  the  requirements  evolution  and  acquisition  milestone  process, 
the  APBs  will  change  focus  from  concept  (Milestone  I)  to  development 
(Milestone  II)  to  production  (Milestone  III).  KPPs  from  the  ORD, 
combined  with  cost  and  schedule  measures,  will  be  included  within  the 
APB  with  their  associated  objectives  and  thresholds.  APBs  are  prepared 
by  the  program  manager  using  the  format  specified  in  Appendix  I  to 
reference  b.  APBs  are  submitted  with  the  required  milestone 
documentation  for  Milestone  I  and  each  succeeding  milestone.  The  KPPs 
objectives  and  thresholds  in  the  APB  must  be  validated  by  the 
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appropriate  authority  before  the  MDA’s  review.  The  MDA  is  the  approval 
authority  for  all  APBs  in  accordance  with  reference  b,  section  3.2.2. 1, 
“Preparation  and  Approval.”  Before  all  major  milestone  decision  reviews 
for  AC  AT  ID,  AC  AT  IAM,  JROC  special  interest  programs  and  for  all  APB 
changes,  the  JROC  will  review  the  APB's  cost,  CAIV  objectives,  schedule, 
and  key  performance  parameters  (objectives  and  thresholds)  to  ensure 
they  satisfy  the  mission  need. 
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APPENDIX  A  TO  ENCLOSURE  E 
OPERATIONAL  REQUIREMENTS  DOCUMENT  FORMAT 


OPERATIONAL  REQUIREMENTS  DOCUMENT 

FOR 

TITLE 

AC  AT _ 

Prepared  for  Milestone _ Decision 

Date 


1.  General  Description  of  Operational  Capability. 

-  Summarize  the  mission  need.  (If  a  documented  MNS  did  not 
precede  the  ORD,  explain  the  process  that  investigated  alternatives  for 
satisfying  mission  need) . 

-  Describe  the  overall  mission  area. 

-  Identify  CRD  the  proposed  system  falls  under  (if  appropriate). 

-  Describe  the  proposed  system. 

-  Describe  the  analysis  that  supports  the  proposed  system. 

-  Define  the  missions  that  the  proposed  system  will  be  tasked  to 
accomplish. 

-  Describe  the  operations  and  suppport  concepts  summarizing  the 
system's  place  on  the  future  battlefield,  its  employment/ operation,  its 
organizational  setting,  and  its  sustaining  and  support  interfaces. 

-  Describe  the  C4ISR  (information  exchange)  operational  concept. 

-  Describe  the  benefits  of  Evolutionary  Acquisition  for  proposed 
system  (if  appropriate).  Requirements  should  be  specified  in  terms  of 
reasonable  increments  of  capability  described  in  the  timeframes  that  will 
support  evolutionary  acquisition  approach.  The  requirements  must  be 
time-based  with  the  initial  capability  targeted  for  a  6  year  IOC  from 
program  initiation.  Requirements  beyond  the  initial  IOC  must  be 
specified  in  a  time  phased  manner  and  be  matched  to  projected  threats. 
Only  those  initial  requirements  that  can  be  validated  by  the  user  as 
needed  within  the  FYDP,  should  be  defined  for  the  initial  acquisition. 
Subsequent  requirements  would  take  into  account  achievements  in 
capability  from  preceding  blocks. 

2.  Threat.  Summarize  the  threat  to  be  countered  and  projected  threat 
environment.  (Reference  DIA  or  Service  Technical  Intelligence  Center 
approved  documents.  For  potential  MDAPs  reference  the  DIA  validated 
threat  assessment.) 
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3.  Shortcomings  of  Existing  Systems  and  C4ISR  architectures. 

-  Describe  why  existing  systems  cannot  meet  current  or  projected 
requirements. 

-  Describe  why  existing  C4ISR  operational,  system  and  technical 
architecture  views  cannot  meet  the  requirements  for  the  proposed 
system. 

4.  Capabilities  required. 

-  Identify  the  operational  performance  parameters  (capabilities 
and  characteristics)  required  for  the  proposed  system. 

-  Articulate  the  requirements  in  output  oriented,  and  measurable 
terms.  Use  Threshold /Objective  format,  and  provide  criteria  and 
rationale  for  each  requirement.  Rationale  should  include  mission  unique 
environment  for  the  system  (e.g.,  wartime,  peace-time,  transition 
conditions) . 

-  Timing  of  requirements  should  specify  the  time-based  nature  of 
the  need  and  the  events  that  are  driving  that  need. 

-  ORD  Key  Performance  Parameters  (KPPs).  Develop  the  ORD 
KPPs  as  outlined  in  Enclosure  D.  Figure  15  provides  example  KPP  table 
summary.  Develop  the  ORD  IERs  matrix,  in  accordance  with  procedures 
described  in  the  C4ISR  Architecture  Framework  and  from  the  IER  matrix 
develop  the  Interoperability  CRD  KPP  as  outlined  in  Enclosure  D. 


Key  Performance  Parameter 

Threshold  and  Objective 

Interoperability 

As  appropriate 

Combat  ID 

" 

Early  Warning 

" 

Etc. 

" 

Figure  15.  Example  KPP  table  summary 

a.  System  Performance. 

-  Describe  mission  scenarios  (wartime  and  peacetime,  if  different)  in 
terms  of  mission  profiles,  employment  tactics,  countermeasures,  and 
environmental  conditions  (all  inclusive:  natural  and  man-made,  e.g., 
weather,  ocean  acoustics,  information  warfare) . 

-  Identify  system  performance  parameters  such  as  range,  accuracy, 
payload,  speed,  mission  reliability,  interoperability,  etc.  Recommend 
which  parameter  shall  be  considered  a  Key  Performance  Parameter. 

b.  Information  Exchange  Requirements.  Identify  the  top  level 
Information  Exchange  Requirements  for  the  system  for  each  mission  area 
that  the  system  is  proposed  to  support  (e.g.,  CAS,  AAW,  surveillance, 
reconnaissance)  as  described  in  Enclosure  E. 
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c.  Logistics  and  Readiness. 

-  Include  measures  for  mission-capable  rate,  operational  availability, 
frequency  and  duration  of  preventive  or  scheduled  maintenance  actions, 
etc. 

-  Describe  in  terms  of  mission  requirements  considering  both 
wartime  and  peacetime  logistics  operations. 

-  Identify  combat  support  requirements  including  battle  damage 
repair  capability,  mobility  requirements,  expected  maintenance  levels, 
and  surge  and  mobilization  objectives  and  capabilities. 

d.  Other  System  Characteristics.  Characteristics  that  tend  to  be 
design,  cost  and  risk  drivers. 

-  Address  electronic  attack  (EA)  and  Wartime  Reserve  Modes 
(WARM)  requirements. 

-  Conventional,  initial  nuclear  weapons  effects,  and  nuclear, 
biological,  and  chemical  contamination  (NBCC)  survivability. 

-  Natural  environmental  factors  (such  as  climatic,  terrain,  and 
oceanographic  factors). 

-  Unplanned  stimuli  (such  as  fast  cook-off,  bullet  impact,  and 
sympathetic  detonation) . 

-  Address  safety  issues  regarding  Hazards  of  Electromagnetic 
Radiation  to  Ordnance  (HERO). 

-  Define  the  expected  mission  capability  (e.g.,  full,  percent  degraded) 
in  the  various  environments.  Include  applicable  safety  parameters  such 
as  those  related  to  system,  nuclear,  explosive,  and  flight  safety. 

-  Identify  physical  and  operational  security  needs. 

5.  Program  Support.  Establish  support  objectives  for  initial  and  full 
operational  capability.  Discuss  interfacing  systems  (at  the 
system/ subsystem,  platform,  and  force  levels),  specifically  those  related 
to  command,  control,  communications,  computers,  and  intelligence  (C4I), 
transportation  and  basing,  and  standardization  and  interoperability. 
Assign  a  joint  potential  designation  (joint,  joint  interest,  or  independent). 

a.  Maintenance  Planning.  Identify  maintenance  tasks  to  be 
accomplished  and  time  phasing  for  all  levels  of  maintenance.  Include 
programmed  maintenance  and  surveillance  inspections  such  as  nuclear 
hardness  and  structural  integrity.  Describe  the  envisioned  planning 
approach  for  contract  versus  organic  repair. 

b.  Support  Equipment.  Define  the  standard  support  equipment  to  be 
used  by  the  system. 
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-  Describe  the  test  and  fault  isolation  capabilities  desired  of 
automatic  test  equipment  at  all  levels,  expressed  in  terms  of  realistic  and 
affordable  probabilities  and  confidence  levels. 

c.  C4I/ Standardization,  Interoperability,  and  Commonality. 

-  Describe  how  the  system  will  be  integrated  into  the  command, 
control,  communications,  computers  and  intelligence  architecture  that  is 
forecast  to  exist  at  the  time  the  system  will  be  fielded.  Include  impact  on 
current/planned  C4ISR  infrastructure,  including  methodology  for 
assessment. 

-  Identify  data  and  data  fusion  requirements  (data,  voice,  video), 
computer  network  support,  and  anti -jam  requirements. 

-  Identify  unique  intelligence  information  requirements,  including 
intelligence  interfaces,  communications,  and  data  base  support 
pertaining  to  target  and  mission  planning  activities,  threat  data,  etc. 

-  Describe  considerations  for  joint  use,  NATO  cross-servicing,  etc. 

-  Identify  procedural  and  technical  interfaces,  and  communications, 
protocols,  and  standards  required  to  be  incorporated  to  ensure 
compatibility  and  interoperability  with  other  Service,  joint  Service,  NATO 
and  other  allied  and  friendly  nation  systems. 

-  The  system  must  comply  with  applicable  information  technology 
standards  contained  in  the  DOD  Joint  Technical  Architecture  (JTA). 

-  Address  interface  requirements  with  Global  Command  and  Control 
System  (GCCS)  or  Common  Operational  Picture  (COP)  (reference  j). 

-  Address  Information  Assurance  (IA)  that  covers  the  defensive 
capabilities  that  provide  for  the  availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation  of  the  information  to  be  exchanged 
and  used.  LA  should  also  include  those  characteristics  needed  for 
restoration  through  protection,  detection,  and  reaction  capabilities.  To 
balance  risks  and  gains,  LA.  and  Information  Interoperability 
characteristics  must  be  co-developed  and  co-evolved.  This  includes 
implementation  of  Public  Key  Infrastructure  (PKI)  required  to  ensure 
information  security  over  all  voice,  video,  and  data  transmission. 
Interconnection  of  systems  operating  at  different  classification  levels 
shall  be  accomplished  by  process  (e.g.,  Secret  and  Below  Interoperability 
(SABI))  that  have  been  approved  by  the  DOD  Chief  Information  Officer 
(CIO)  (references  h  and  i). 

-  Address  energy  standardization  and  efficiency  needs  for  both  fuels 
and  electrical  power  as  applicable. 

-  Address  Electromagnetic  Environmental  Effects  (E3)  and  Spectrum 
Supportability  for  systems  and  equipment. 
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d.  Computer  Resources 

-  Identify  computer  resource  constraints  (examples  include 
language,  computer,  database,  architecture,  or  interoperability 
constraints). 

-  Address  all  mission  critical  and  support  computer  resources, 
including  automated  test  equipment. 

-  Describe  the  capabilities  desired  for  integrated  computer  resources 
support. 

-  Identify  any  unique  user  interface  requirements,  documentation 
needs,  and  special  software  certifications. 

e.  Human  Systems  Integration.  Address  HSI  domains  to  include: 

-  Establish  broad  manpower  constraints  for  operators,  maintainers, 
and  support  personnel. 

-  Identify  requirements  for  manpower  factors  that  impact  system 
design  (utilization  rates,  pilot-to-seat  ratios,  and  maintenance  ratios). 

-  Establish  broad  cognitive,  physical,  and  sensory  requirements  for 
the  operators,  maintainers,  or  support  personnel  that  contribute  to,  or 
constrain,  total  system  performance. 

-  Establish  requirements  for  human  performance  that  will  achieve 
effective  human-system  interfaces.  Identify  requirements  for  combining, 
modifying,  or  establishing  new  military  occupational  specialties. 

-  Describe  the  training  concept  to  include  requirements  for  training 
support  package  (e.g.  simulators,  training  devices,  embedded  training), 
and  training  logistics.  Include  safety  or  health  and  critical  errors  that 
reduce  job  performance  or  system  effectiveness  given  the  operational 
environment.  Determine  objectives  and  thresholds  for  the  above 
requirements,  as  appropriate. 

f.  Other  Logistics  and  Facilities  Considerations. 

-  Describe  the  provisioning  strategy  for  the  system. 

-  Specify  any  unique  facility,  shelter,  supporting  infrastructure, 
environmental  compliance  requirements,  and  associated  costs  and 
availability  milestone  schedule  in  support  of  the  requirement. 

-  Identify  special  packaging,  handling,  and  transportation 
considerations . 

-  Define  unique  data  requirements  such  as  engineering  data  for 
depot  support  and  technical  orders  for  the  system  and  depot. 

g.  Transportation  and  Basing.  Describe  how  the  system  will  be 
moved  either  to  or  within  the  theater.  Identify  any  lift  constraints.  Detail 
the  basing  requirements  (main  and  forward  operating  bases)  and 
associated  facilities  needed  for  training. 
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h.  Geospatial  Information  and  Services.  Identify  cartographic 
materials,  digital  topographic  data,  and  geodetic  data  needed  for  system 
employment.  Where  possible,  National  Imagery  &  Mapping  Agency 
standard  military  data  shall  be  used. 

i.  Natural  Environmental  Support.  Identify  the  standard  and  unique 
weather,  oceanographic,  and  astrogeophysical  support  required.  Include 
data  accuracy  and  forecast  requirements. 

6.  Force  Structure.  Estimate  the  number  of  systems  or  subsystems 
needed,  including  spares  and  training  units.  This  is  only  an  estimate  of 
the  number  of  systems  /subsystems  needed,  and  will  not  serve  as  the 
definitive  source  for  documenting  the  distribution  or  basis  of  issue. 
Identify  units  or  platforms  and  quantities  of  these  platforms  (including 
other  Services'  or  Government  agencies'  if  appropriate)  that  will  employ 
the  systems  or  subsystems  being  developed  and  procured  to  satisfy  this 
Operational  Requirements  Document. 

7.  Schedule.  Define  what  actions,  when  complete,  will  constitute 
attainment  of  Initial  and  Full  Operational  Capability  (leave  flexible  for 
these  to  be  revised  as  the  program  is  progressively  defined  and  trade-off 
studies  are  completed). 

-  Clearly  specify  the  operational  capability  or  level  of  performance 
necessary  to  declare  Initial  and  Full  Operational  Capability.  Include  the 
number  of  operational  systems,  operational  and  support  personnel, 
facilities,  supporting  infrastructure  and  organizational,  intermediate,  and 
depot  support  elements  that  must  be  in  place.  If  availability  in  a  specific 
timeframe  is  important,  specify  an  objective  for  initial  operational 
capability.  Describe  the  impact  if  this  objective  is  not  achieved  and 
identify  a  window  of  acceptability  if  appropriate. 

8.  Program  Affordability.  Cost  will  be  addressed  in  the  ORD.  Inclusion 
of  cost  allows  the  DOD  component  sponsor  to  emphasize  affordability 
early  in  the  proposed  program.  The  cost  figure  should  be  stated  in  terms 
of  a  threshold  and  objective  (not  necessarily  a  KPP)  in  order  to  provide 
flexibility  to  allow  for  program  evolution  and  CAIV  trade  studies.  The 
DOD  component  sponsor  may  make  cost  a  KPP  if  it  desires  and  identify 
the  cost  it  wishes  to  evaluate.  The  cost  will  be  extracted  from  the  ORD 
and  included  in  the  cost  section  of  the  APB. 
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GLOSSARY 

PART  I— ABBREVIATIONS  AND  ACRONYMS 
Acquisition  Category 

Advanced  Concept  Technology  Demonstration 

Analysis  of  Alternatives 

Acquisition  Program  Baseline 

Automated  Information  System 

Assistant  Secretary  of  Defense  (Command,  Control, 
Communications  and  Intelligence) 

Command,  Control,  Communications,  and  Computers 

Command,  Control,  Communications,  Computers,  and 
Intelligence 

Command,  Control,  Communications,  Computers,  and 
Intelligence  Support  Plan 

Command,  Control,  Communications,  Computers, 
Intelligence,  Surveillance,  and  Reconnaissance 

Cost  as  an  Independent  Variable 

Capstone  Requirements  Document 

Defense  Acquisition  Board 

Defense  Intelligence  Agency 

Department  of  Defense  Directive 

Defense  Planning  Guidance 

Electromagnetic  Environment  Effects 
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FoS 

Family  of  Systems 

IA 

Information  Assurance 

IER 

Information  Exchange  Requirement 

IOC 

Initial  Operational  Capability 

IPT 

Integrated  Product  Team 

ITOIPT 

Information  Technology  Overarching  Integrated 
Product  Team 

JMAA 

Joint  Mission  Area  Analysis 

JMNA 

Joint  Mission  Need  Analysis 

JPD 

Joint  Potential  Designator 

JRB 

Joint  Requirements  Board 

JROC 

Joint  Requirements  Oversight  Council 

JROCM 

JROC  memorandum 

JROCSM 

JROC  Staff  memorandum 

JRP 

Joint  Requirements  Panel 

JTA 

Joint  Technical  Architecture 

KPP 

Key  Performance  Parameter 

MAA 

Mission  Area  Analysis 

MAIS 

Major  Automated  Information  System 

MCEB 

Military  Communications-Electronics  Board 

MDA 

Milestone  Decision  Authority 

MDAP 

Major  Defense  Acquisition  Program 
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MIB 

Military  Intelligence  Board 

MNA 

Mission  Needs  Analysis 

MNS 

Mission  Need  Statement 

MOE 

Measure  of  effectiveness 

MS 

Milestone 

NATO 

North  Atlantic  Treaty  Organization 

NBCC 

Nuclear,  Biological,  and  Chemical  Contamination 

POC 

Point  of  Contact 

PSA 

Principal  Staff  Assistant 

ORD 

Operational  Requirements  Document 

RAD 

Requirements  and  Acquisition  Division 

RDT&E 

Research,  Development,  Test,  and  Evaluation 

SoS 

System  of  Systems 

SSG 

Senior  Steering  Group 

SWARF 

Senior  Warfighting  Forum 

TEMP 

Test  and  Evaluation  Master  Plan 

USD(A&T) 

Under  Secretary  of  Defense  for  Acquisition  and 
Technology 

USACOM 

United  States  Atlantic  Command 

USSOCOM 

United  States  Special  Operations  Command 
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PART  II--DEFIN1TIONS 

Acquisition  Category  (ACAT) .  Categories  established  to  facilitate 
decentralized  decision  making  and  execution,  and  compliance  with 
statutorily  imposed  requirements.  The  categories  determine  the  level  of 
review,  decision  authority,  and  applicable  procedures.  DOD  5000. 2-R, 
part  1 ,  provides  the  specific  definition  for  each  acquisition  category 
(ACAT  I  through  III). 

ACAT  I.  A  major  defense  acquisition  program  (MDAP)  subject  to  Defense 
Acquisition  Board  oversight  and  estimated  by  the  USD(A&T)  to  require  an 
eventual  total  expenditure  of  more  than  $355  million  in  RDT&E  funds,  or 
$2,135  billion  in  procurement  funds  measured  in  FY1996  constant 
dollars. 

ACAT  ID.  A  major  defense  acquisition  program  (MDAP)  for  which  the 
MDA  is  USD(A&T).  The  "D"  refers  to  the  Defense  Acquisition  Broad 
(DAB),  which  advises  the  USD(A&T)  at  major  decision  points 

ACAT  IC.  A  major  defense  acquisition  program  subject  for  which  the 
MDA  is  the  DOD  Component  Head,  or  if  delegated,  the  DOD  Component 
Acquisition  Executive  (CAE).  The  "C"  refers  to  Component. 

ACAT  IA.  A  major  automated  information  system  (MAIS)  acquisition 
program  that  is  estimated  to  require  program  costs  in  any  single  year  in 
excess  of  $30  million,  total  program  costs  in  excess  of  $120  million,  or 
total  life  cycle  costs  in  excess  of  $360  million  (FY  1996  constant  dollars). 

ACAT  LAM.  A  major  automated  information  system  (MAIS)  acquisition 
program  for  which  the  MDA  is  the  Chief  Information  Officer  (CIO)  of  the 
Department  of  Defense  (DOD),  the  ASD(C3I). 

ACAT  I  AC.  A  major  automated  information  system  acquisition  program 
for  which  the  DOD  CIO  has  delegated  milestone  decision  authority  to  the 
CAE  or  Component  CIO.  The  "C"  (in  ACAT  IAC)  refers  to  Component. 

Acquisition  Program  Baseline  (APB).  Each  baseline  is  developed  and 
updated  by  the  program  manager  and  will  govern  the  activity  in  the 
phase  succeeding  the  milestone  for  which  it  was  developed.  The  Concept 
Baseline,  Development  Baseline,  and  Production  Baseline  are  prepared 
at  Milestone  I,  II,  and  III,  respectively.  APBs  consist  of  three  parts; 
section  A— performance  (contains  KPPs),  section  B— schedule,  and  section 
C— cost. 
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Advanced  Concept  Technology  Demonstration  (ACTD).  The  primary  goal 
of  an  ACTD  is  to  assess  the  military  utility  of  a  significant  new  capability 
and  to  conduct  the  assessment  as  a  scale  size  adequate  to  clearly 
establish  operational  utility  and  system  integrity. 

Approval.  The  formal  or  official  sanction  of  the  identified  need  described 
in  the  requirements  documentation.  Approval  also  certifies  that  the 
documentation  has  been  subject  to  the  uniform  process  established  by 
DOD  5000  series. 

Analysis  of  Alternatives  (AO A) .  The  evaluation  of  the  operational 
effectiveness  and  estimated  costs  of  alternative  material  systems  to  meet 
a  mission  need.  The  analysis  assesses  the  advantages  and 
disadvantages  of  alternatives  being  considered  to  satisfy  requirements,  to 
include  the  sensitivity  of  each  alternative  to  possible  changes  in  key 
assumptions  or  variables.  The  AOA  assists  decision  makers  in  selecting 
the  most  cost-effective  material  alternative  to  satisfy  a  mission  need. 

Architecture.  The  structure  of  components,  their  relationships,  and  the 
principles  and  guidelines  governing  their  design  and  evolution  over  time. 

Automated  Information  Systems  (AIS) .  A  combination  of  computer 
hardware  and  software,  data,  telecommunications,  that  performs 
functions  such  as  collecting,  processing,  transmitting,  and  displaying 
information.  An  AIS  can  include  computer  hardware  only,  computer 
software  only,  or  a  combination  of  the  above.  Excluded  are  computer 
resources,  both  hardware  and  software,  that  are  physically  part  of, 
dedicated  to,  or  essential  in  real  time  to  the  mission  performance  of 
weapon  systems. 

C4I  Support  Plans.  The  purpose  of  the  C4ISP  is  to  provide  a  window 
into  a  specific  system  development  program  through  which  can  be  seen 
any  shortfalls  in  the  C4I  required  for  each  phase  of  the  system's  life 
cycle. 

Certification.  Statement  of  adequacy  provided  by  a  responsible  agency 
for  a  specific  area  of  concern  in  support  of  the  validation  process. 

Capstone  Requirements  Document  (CRD) .  A  document  that  contains 
capabilities-based  requirements  that  facilitates  the  development  of 
individual  ORDs  by  providing  a  common  framework  and  operational 
concept  to  guide  their  development.  It  is  an  oversight  tool  for 
overarching  requirements  for  a  system-of-systems  or  family-of-systems. 
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Core  Capability.  The  core  capability  includes  the  following:  1 .  The  set  of 
functions  that  define  a  significant,  stand-alone,  operationally  effective, 
and  suitable  military  capability  such  that,  should  no  further 
development  occur,  the  user  will  have  received  a  significant  capability. 

2.  The  integral  characteristics  of  the  system  that,  if  altered  in 
subsequent  increments,  would  lead  to  significant  redesign  of  the 
evolutionary  system. 

POD  Component.  OSD,  the  Military  Departments,  the  Chairman  of  the 
Joint  Chiefs  of  Staff  (Joint  Staff),  the  unified  and  specified  commands 
(including  US  Element,  NORAD),  Defense  agencies,  and  DOD  field 
activities. 

DOD  5000  Series.  Refers  collectively  to  DODD  5000.1  and  DOD 
5000.2-R. 


Electromagnetic  Environmental  Effects  (E3).  E3  is  the  impact  of  the 
electromagnetic  environment  upon  the  operational  capability  of 
militaryforces,  equipment,  systems,  and  platforms.  It  encompasses  all 
electromagnetic  disciplines,  including  electromagnetic 
compatibility /electromagnetic  interference;  electromagnetic  vulnerability, 
electromagnetic  pulse;  electromagnetic  protection;  hazardsof 
electromagnetic  radiation  to  personnel,  ordnance,  andvolatile  materials; 
and  natural  phenomena  effects,  of  lightning  and  p-static. 

Evolutionary  Acquisition.  Evolutionary  acquisition  is  a  streamlined 
acquisition  strategy  that  fields  a  core  capability,  with  a  modular  open 
structure  and  provides  for  additional  future  increments  in  capability 
upgrades. 

F amily- of- Systems .  A  set  or  arrangement  of  independent  systems  that 
can  be  arranged  or  interconnected  in  various  ways  to  provide  different 
capabilities.  The  mix  of  systems  can  be  tailored  to  provide  desired 
capabilities  dependent  on  the  situation. 

Information  Assurance  (LA) .  IO  that  protect  and  defend  information  and 
information  systems  by  ensuring  their  availability,  integrity, 
authentication,  confidentiality,  and  non-repudiation. 

Information  Exchange  Requirements.  The  requirement  for  information  to 
be  passed  between  and  among  forces,  organizations,  or  administrative 
structures  concerning  ongoing  activities.  Information  exchange 
requirements  identify  who  exchanges  what  information  with  whom,  as 
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well  as  why  the  information  is  necessary  and  how  that  information  will 
be  used.  The  quality  (i.e.  frequency,  timeliness,  security)  and  quantity 
(i.e.,  volume,  speed,  and  type  of  information  such  as  data,  voice,  and 
video)  are  attributes  of  the  information  exchange  included  in  the 
information  exchange  requirement. 

Interoperability.  (1)  The  ability  of  systems,  units,  or  forces  to  provide 
services  to  and  accept  services  from  other  systems,  units,  or  forces  and 
to  make  use  the  services,  units,  or  forces  and  to  use  the  services  so 
exchanged  to  enable  them  to  operate  effectively  together.  (2)  The 
condition  achieved  among  communications-electronics  systems  or  items 
of  communications-electronics  equipment  when  information  or  services 
can  be  exchanged  directly  and  satisfactorily  between  them  and/or  their 
users.  The  degree  of  interoperability  should  be  defined  when  referring  to 
specific  cases. 

Implementation .  The  publication  of  directives,  instructions,  regulations, 
and  related  documents  that  define  responsibilities  and  authorities  and 
establish  the  internal  management  processes  necessary  to  implement  the 
policies  or  procedures  of  a  higher  authority. 

Insensitive  Munitions.  Insensitive  munitions  minimize  the  probability  of 
inadvertent  initiation  and  the  severity  of  subsequent  collateral  damage  as 
a  result  of  unplanned,  external  stimuli. 

Joint  Experimentation.  An  iterative  process  for  developing  and  assessing 
concept-based  hypotheses  to  identify  and  recommend  the  best  value- 
added  solutions  for  changes  in  doctrine,  organizational  training  and 
education,  materiel,  leadership,  and  personnel  required  to  achieve 
significant  advances  in  future  joint  operational  capabilities. 

Joint  Potential  Designator  (JPD).  Used  to  describe  the  expected  level  of 
joint  DOD  component  involvement. 

a.  Independent.  No  potential  for  other  Service  use  or  systems 
interface  or  for  joint  development  or  procurement. 

b.  Joint  Interest.  Joint  program  management  is  inappropriate, 
but  a  potential  for  other  Service  use  or  systems  interface  exists. 

c.  Joint.  A  potential  for  joint  program  management,  joint  funding, 
and/or  joint  development  or  procurement  exists. 
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Joint  Requirements  Oversight  Council  Memorandum  (JROCM).  Official 
JROC  correspondence  generally  directed  to  an  audience  (s)  external  to  the 
JROC.  Usually  decisional  in  nature. 

Joint  Requirements  Oversight  Council  Staff  Memorandum  (JROCSM). 
Official  JROC  correspondence  generally  utilized  for  internal  staffing  and 
tasking.  Usually  pre-decisional  in  nature  and  not  releasable  outside  of 
JROC  circles. 

Joint  Technical  Architecture.  The  JTA  provides  DOD  systems  with  the 
basis  for  the  needed  seamless  interoperability.  The  JTA  defines  the 
service  areas,  interfaces,  and  standards  (JTA  elements)  applicable  to  all 
DOD  systems,  and  its  adoption  is  mandated  for  the  management, 
development,  and  acquisition  of  new  or  improved  systems  throughout 
DOD.  The  JTA  is  structured  into  service  areas  based  on  the  DOD 
Technical  Reference  Model  (TRM).  The  DOD  TRM  originated  from  the 
Technical  Architecture  Framework  for  Information  Management  (TAFIM), 
and  was  developed  to  show  which  interfaces  and  content  needed  to  be 
identified.  The  JTA  consists  of  two  main  parts:  the  JTA  core,  and  the 
JTA  Annexes.  The  JTA  core  contains  the  minimum  set  of  JTA  elements 
applicable  to  all  DOD  systems  to  support  interoperability. 

JROC  Special  Interest.  Programs  identified  by  the  JROC  Secretary  as 
being  of  interest  to  the  JROC  for  oversight  even  though  they  do  not  meet 
the  ACAT  I  cost  thresholds  or  have  been  designated  as  ACAT  ID. 

Key  Performance  Parameters  (KPPs).  Those  capabilities  or  characteristics 
considered  most  essential  for  successful  mission  accomplishment. 

Failure  to  meet  an  ORD  KPP  threshold  can  be  cause  for  the  concept  or 
system  selection  to  be  reevaluated  or  the  program  to  be  reassessed  or 
terminated.  Failure  to  meet  a  CRD  KPP  threshold  can  be  cause  for  the 
family- of- systems  or  system-of-systems  concept  to  be  reassessed  or  the 
contributions  of  the  individual  systems  to  be  reassessed.  KPPs  are 
validated  by  the  JROC.  ORD  KPPs  are  included  in  the  APB. 

Lead  DOD  Component.  The  Service  or  agency  that  has  been  formally 
designated  as  lead  for  a  joint  program  by  the  MDA.  The  lead  component 
is  responsible  for  all  common  documentation,  periodic  reporting,  and 
funding  actions. 

Major  Automated  Information  System  (MAIS)  Program.  An  automated 
information  system  acquisition  program  that  is  estimated  to  require 
program  costs  in  any  single  year  in  excess  of  $30  million,  total  program 
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costs  in  excess  of  $120  million,  or  total  life  cycle  costs  in  excess  of  $360 
million  (FY  1996  constant  dollars). 

Major  Defense  Acquisition  Program  (MDAP).  An  acquisition  program  that 
is  not  a  highly  sensitive  classified  program  and  is  estimated  by  the 
USD(A&T)  to  require  an  eventual  total  expenditure  of  more  than  $355 
million  in  RDT&E  funds,  $2,135  billion  in  procurement  funds  measured 
in  FY  1996  constant  dollars,  or  programs  designated  as  an  MDAP  by  the 
USD(A&T). 

Materiel  Solution.  A  defense  acquisition  program  (non-developmental, 
modification  of  existing  systems,  or  new  program)  that  satisfies  identified 
mission  needs. 

Milestones.  Major  decision  points  that  separate  the  phases  of  an 
acquisition  program. 

Milestone  Decision  Authority.  The  individual  disignated  in  accordance 
with  criteria  established  by  the  USD(A&T),  or  by  the  ASD(C3I)  for  AIS 
acquisition  programs,  to  approve  entry  of  an  acquisition  program  into  the 
next  phase. 

Military  Department.  Headed  by  a  civilian  Secretary  appointed  by  the 
President  and  includes  a  Military  Service  (the  Department  of  the  Navy 
includes  two  Services). 

Military  Service.  Headed  by  a  uniformed  member  who  reports  to  the 
civilian  Secretary  heading  the  Military  Department  of  which  the  Service  is 
a  part. 


Mission  Area  Analysis  (MAA) .  An  analysis  that  uses  a  “strategy-to  task” 
(e.g.,  National  Military  Strategy  to  individual  mission  tasks)  methodology 
to  identify  the  operational  support  tasks  needed  to  achieve  military 
objectives. 

Mission  Need.  A  deficiency  in  current  capabilities  or  an  opportunity  to 
provide  new  capabilities  (or  enhance  existing  capabilities)  through  the 
use  of  new  technologies.  They  are  expressed  in  broad  operational  terms 
by  the  DOD  components. 

Mission  Needs  Analysis  (MNA).  An  analysis  designed  to  assess  ones 
ability  to  accomplish  the  tasks  identified  during  the  MAA.  The  Analysis 
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uses  a  task-to-need  methodology  to  identify  mission  needs.  It  can  also 
highlight  technological  opportunities  and  identify  reliability  and 
maintainability  improvements  that  enhance  warfighting  capability. 

Mission  Need  Statement  (MNS).  A  formatted  non-system-specific 
statement  containing  operational  capability  needs  and  written  in  broad 
operational  terms.  It  describes  required  operational  capabilities  and 
constraints  to  be  studied  during  the  Concept  Exploration  and  Definition 
Phase. 

Non-major  Defense  Acquisition  Program.  Does  not  meet  criteria  for  a 
MDAP.  Further  defined  as  ACAT  II  or  III  in  DOD  5000. 2-R,  part  1. 

Non-materiel  Solution.  Changes  in  doctrine,  tactics,  training,  or 
organization  to  satisfy  identified  mission  needs.  MNSs  with  an  identified 
non-materiel  solution  are  sent  to  the  Military  Departments  for 
consideration  and  action. 

Objective.  An  operationally  significant  increment  above  the  threshold. 

An  objective  value  may  be  the  same  as  the  threshold  when  an 
operationally  significant  increment  above  the  threshold  is  not  significant 
or  useful. 

Operational  Architecture  View.  A  description  (often  graphical)  of  the 
tasks  and  activities,  operational  elements,  and  information  flows  required 
to  accomplish  or  support  a  warfighting  function. 

Operational  Requirements.  A  system  capability  or  characteristic  required 
to  accomplish  approved  mission  needs.  Operational  (including 
supportability)  requirements  are  typically  performance  parameters,  but 
they  may  also  be  derived  from  cost  and  schedule.  For  each  parameter, 
an  objective  and  threshold  value  must  also  be  established. 

Operational  Requirements  Document  (ORD).  A  formatted  statement 
containing  performance  and  related  operational  parameters  for  the 
proposed  concept  or  system.  Prepared  by  the  user  or  user's 
representative  at  each  milestone  beginning  with  Milestone  I. 

Operational  Validation  Authority.  Designated  authority  responsible  for 
confirming  the  user's  identified  need  and  operational  requirement. 
Designation  of  this  operational  validation  authority  is  the  responsibility 
of  the  MDA  and  will  vary  between  DOD  components  and  the  ACAT  level 
of  the  program. 
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Operator.  An  operational  command  or  agency  that  employs  the  acquired 
system  for  the  benefit  of  users.  Operators  may  also  be  users. 

Originator.  A  DOD  component  or  operational  command  that  initiates  a 
MNS.  The  originator  may  or  may  not  be  the  sponsor. 

Principal  Staff  Assistant  (PSA) .  Represents  the  user  community  in  the 
functional  area  under  their  direction  on  acquisition  and  requirements 
matters.  The  OSD  PSAs  are  the  Under  Secretaries  of  Defense  (USDs),  the 
Director  of  Defense  Research  and  Engineering  (DDR&E),  the  Assistant 
Secretaries  of  Defense  (ASDs),  the  Director,  Operational  Test  and 
Evaluation  (DOT&E),  the  General  Counsel  of  the  Department  of  Defense 
(GC,  DOD),  the  Inspector  General  of  the  Department  of  Defense  (IG, 

DOD),  the  Assistants  to  the  Secretary  of  Defense  (ATSDs),  and  the  OSD 
Directors  or  equivalents,  who  report  directly  to  the  Secretary  or  the 
Deputy  Secretary  of  Defense. 

Requirement.  The  need  of  an  operational  user,  initially  expressed  in 
broad  operational  capability  terms  in  the  format  of  a  MNS.  It 
progressively  evolves  to  system-specific  performance  requirements  in  the 
ORD. 

Sponsor.  The  DOD  component  responsible  for  all  common 
documentation,  periodic  reporting,  and  funding  actions  required  to 
support  the  requirements  and  acquisition  process. 

Supplementation .  The  publication  of  directives,  instructions, 
regulations,  and  related  documents  that  add  to,  restrict,  or  otherwise 
modify  the  policies  or  procedures  of  a  higher  authority. 

System  Capabilities.  Measures  of  performance  such  as  range,  lethality, 
maneuverability,  and  survivability. 

System  Characteristics.  Design  features  such  as  weight,  fuel  capacity, 
and  size.  Characteristics  are  usually  traceable  to  capabilities  (e.g., 
hardening  characteristics  are  derived  from  a  survival  capability)  and  are 
frequently  dictated  by  operational  constraints  (e.g.,  carrier  compatibility) 
and/or  the  intended  operational  environment  (e.g.,  NBC). 

System-of-Systems.  A  set  or  arrangement  of  systems  that  are  related  or 
connected  to  provide  a  given  capability.  The  loss  of  any  part  of  the 
system  will  degrade  the  performance  or  capabilities  of  the  whole. 
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System  Architecture  View.  A  description,  including  graphics,  of  systems 
and  interconnections  providing  for  or  supporting  warfighting  functions. 

Senior  Warfighting  Forum.  JROC  directed  forum  used  to  organize, 
analyze,  prioritize,  and  frame  complex  warfighter  resource  and 
requirements  issues  for  JROC  approval.  JROC  tasking  memorandum  will 
identify  the  scope,  sponsor  and  supporting  agencies  to  frame  issues. 

Technical  Architecture  View.  A  minimal  set  of  rules  governing  the 
arrangement,  interaction,  and  interdependence  of  system  parts  or 
elements,  whose  purpose  is  to  ensure  that  a  conformant  system  satisfies 
a  specified  set  of  requirements. 

Threshold.  A  minimum  acceptable  operational  value  below  which  the 
utility  of  the  system  becomes  questionable. 

User.  An  operational  command  or  agency  that  receives  or  will  receive 
benefit  from  the  acquired  system.  CINCs  and  their  Service  component 
commands  are  the  users.  There  may  be  more  than  one  user  for  a 
system.  The  Service  component  commands  are  seen  as  users  for 
systems  required  to  organize,  equip,  and  train  forces  for  the  CINCs.  The 
Chiefs  of  the  Services  and  heads  of  other  DOD  components  are  validation 
and  approval  authorities  and  are  not  viewed  as  users. 

User  Representative.  A  command  or  agency  that  has  been  formally 
designated  by  proper  authority  to  represent  single  or  multiple  users  in 
the  requirements  and  acquisition  process.  The  Services  and  the  Service 
components  of  the  CINCs  are  normally  the  user  representatives.  There 
should  only  be  one  user  representative  for  a  system. 

Validation.  The  review  of  documentation  by  an  operational  authority 
other  than  the  user  to  confirm  the  need  or  operational  requirement.  As  a 
minimum,  the  operational  validation  authority  reviews  the  MNS, 
confirms  that  a  nonmateriel  solution  is  not  feasible,  assesses  the  joint 
Service  potential,  and  forwards  a  recommendation  to  the  MDA  for 
Milestone  0  action.  Validation  is  a  necessary,  but  not  sufficient,  step  for 
approval.  This  step  appears  identical  to  approval  in  the  case  of  a  MNS, 
but  the  JROC  may  delegate  final  ORD  approval  authority  while  retaining 
validation  authority. 
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